建模语言之模型容器

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

一. 容器模型

如图所示，这是一个简化的类图，容器模型包含了各种模型元素，相互之间有各种关系：

• 工作空间由产品和应用组合而成
• 组件包含了多种类型的子类：产品组件、应用组件、业务组件、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_