建模语言中有各种模型、图表,需要分类存放,模型容器就是为了存放各种模型,是一些逻辑上的容器,这点上,与通常的模型语言有所差异。
一. 容器模型

如图所示,这是一个简化的类图,容器模型包含了各种模型元素,相互之间有各种关系:
- 工作空间由产品和应用组合而成
- 组件包含了多种类型的子类:产品组件、应用组件、业务组件、UI模型组件、DB组件等
- 一个产品有且仅有一个产品组件,一个应用有且仅有一个应用组件
- 产品与应用之间是多对多的交叉关系
本章介绍的容器模型,是元型平台使用的容器模型,这里介绍是为了后面我们在做具体的模型设计讲解过程中,能更好的理解设计过程,此处的定义与通常所说的这些词汇可能有些差异,需要认真理解。
二. 工作空间(WorkScope)
是所有建模及开发工作的基础,是模型的隔离单元,不能跨工作空间引用,所有产品、应用都必须指定到工作空间中,并且服务地址也会由工作空间构成。
【规则】
- 名称在平台内全局唯一,必须至少6位且包含字母和数字,以字母开头,最长16位;
- 名称一旦保存不可修改;
- 所有产品、应用必须指定工作空间,工作空间下一旦拥有产品或应用,则不能删除;
- 每个工作空间具有唯一的一个测试产品,测试产品由平台生成;
【最佳实践】
使用域名作为工作空间名称,例如:假设域名为xxx.com,则工作空间名称ComXXX或XXX;
三. 产品(Product)
一个产品是一套完整的程序,独立运行,具有一个管理后台以及多个微服务,一个用户可以创建多个产品,一个产品下有且只有一个产品组件;
【规则】
- 必须归属于某一个工作空间;
- 名称:在工作空间下唯一,必须至少8位且包含字母和数字,以字母开头,最长24位;
- 根名字空间:类似于C#的名字空间或Java的包路径;
- 测试产品由平台生成,用户不能修改和删除;
- 每个产品都必须包含唯一的一个系统应用,系统应用由平台自动生成;
【最佳实践】
根名字空间采用全小写,使用三段比较合适,例如:com.xxx.productname;
四. 应用(Application)
一套内聚性高的业务模型的集合,不能跨应用引用;对应运行期的一个微服务,最小的可部署单元,通过应用可以组合成不同的产品,应用由组件构成,应用包含的模型也是模型复制等功能的最小单元;
【规则】
- 必须归属于某一个工作空间;
- 名称:在工作空间下唯一,必须至少8位且包含字母和数字,以字母开头,最长24位;
- APPKey:每个应用有一个全局的唯一标识,由字母和数字构成;
- 根名字空间:类似于C#的名字空间或Java的包路径;
【最佳实践】
类似于产品,根名字空间采用全小写,使用四段比较合适,例如:com.xxx.app.appname;
五. 组件(Component)
模型的最小单位,定义了业务关系紧密的业务模型,跨组件可以进行弱引用,包括多种细分组件:
- 产品组件(ProductComponent):定义产品的元数据,以及包含的应用等;
- 应用组件(AppComponent):定义应用的元数据,以及菜单、任务等;
- 业务模型组件(BEComponent):基于UML类图扩展,定义静态业务模型,包括实体、商业逻辑等;
- 界面模型组件(UIModelComponent):定义界面相关的元数据,由业务模型一对一生成,需要用户基于默认转换进行个性化设置,从而控制前端代码及页面呈现;
- 数据库模型组件(DBComponent):数据库模型,定义数据库结构,由业务模型一对一生成,用户不可编辑;
【规则】
- 根名字空间:在应用的根名字空间后面,增加一段组件的名称来构成;
- 简称:组件名称的简称,主要使用在创建数据库表的时候当作前缀使用,由于长度限制,尽量使用有意义的短名称;
- 组件类型:包含上述所列举的类型,不可修改,不用的类型可使用的模型元素不一样;
- 每个应用有且只有一个应用组件,每个产品有且只有一个产品组件;
- 数据库组件完全由平台生成,对用户不可见;
【最佳实践】
简称,可采用下划线将几段简称组合而成,例如:名空间简称_应用简称_组件简称_,MP_AS_B_