本文源于人人精通模块设计系列的多彩的领域建模战术设计，将向大家简要介绍如何基于领域元素设计出领域模型、领域模型与4+1视图的关系和如何输出4+1视图。
人人精通模块设计的多彩的领域建模战略设计、多彩的领域建模战术设计，已经形成精品课程，当前已经在多个基层团队赋能应用，有诉求的小伙伴可以联系姜皓00267218。
多彩的领域建模与4+1视图的关系
最近和很多小伙伴一起应用多彩的领域建模方法完成战略、战术设计、4+1视图，有不少人都会问：为什么软件设计要开展战略、战术、4+1这么多活动呢？为什么要搞这么复杂呢？
复杂性思维的理论可以帮助我们理解这个事。复杂性思维理论告诉我们需要以复杂应对复杂，才能抽象出系统的元素以及一般规则，只要明白这些就能很好的建模整个系统。即分解出来的看似简单的个体，在简单规则之下会形成复杂的系统。鸟群如何在没有领导和全局信息的指导下，完成复杂的群体飞行？计算机图形专家用BOID的模型模拟鸟群，只需要设定三条简单的规则就可以形成：一 靠近，二 对齐，三 适当分离。展现出的变化多端复杂无比的形式，其实只建立在简单的规则之上的。
领域建模的方法也应用了这个思想，它聚焦业务知识，抽象出一系列的领域、领域元素以及各领域元素之间的关系，实现了从复杂业务的澄清到基于领域和领域元素的制定解决方案，最后针对每一种方案设计落地过程的细节。其实，“领域驱动”，其实就是“问题/需求驱动”——从澄清关键业务问题开始，逐渐寻找适合的解决方案，再到确定实现细节的过程。因此，整个领域建模过程中，从需求到子域、上下文的设计过程就是制定解决方案的战略设计，领域建模的实现细节确定就是战术设计。
那这又与4+1视图有什么关系呢？
先说说4+1视图，它是对逻辑架构进行描述，最早由 Philippe Kruchten 提出，他在1995年的《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，引起了业界的极大关注，并最终被 RUP 采纳，现在已经成为架构设计的结构标准。因此，它是架构设计的一种标准展现形式，5个视图一起展示了一个系统架构的全貌。简化言之，它就是架构的一种标准展现形式。
公司对4+1视图要求见下图1，5个视图下，共涉及13个模型。
图1. 公司4+1视图要求脑图（简化版）注：完整版链接
从4+1视图的内部联系可以看出，场景视图和逻辑视图是4+1视图的核心，是架构的内部视角，其他视图都是基于这两个视图，外部视角的呈现形式。它们的关系见图2。
图2. 4+1视图的内部关系
再看看领域模型，它是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。
从这个定义中，我们可以看到一些关键词“业务用例“、“对象模型”、“业务角色和业务实体之间的联系和协作”。我们可以用一张图来解释这一切，见图3，即业务角色需要完成某个业务（用例），这个用例被某些模块/组件/服务承载，最终由分层架构实现。
图3. 领域模型宏观框图
因此，领域模型主要是描述了业务场景和业务逻辑，对应的正是4+1视图的“场景视图和逻辑视图”这两个核心视图。
多彩的领域建模输出的就是领域模型，因此它可以作为输出4+1视图的方法，而多彩的领域建模的战略、战术设计是输出4+1视图的分析过程。4+1视图的13个模型，如何通过多彩的领域建模方法输出，我们通过图3就能有一个大致的了解。
图4. 多彩领域建模是设计方法和过程，4+1视图是设计结果
通过多彩的领域建模输出4+1视图
我们假设领域建模已经完成，接下来我们一起看看如何输出场景视图和逻辑视图（需要进一步了解领域建模的方法和其他视图如何输出可以联系我）。
用例模型和逻辑模型，公司对期的要求和建议如表1.：
|
视图 |
模型名称 |
模型说明 |
元素 |
|
用例视图 |
上下文模型（必选） |
系统与周边关系 |
系统，对外接口 |
|
用例模型（可选，典型用例） |
通过用例贯穿上述4个视图 |
用例 |
|
|
逻辑视图 |
领域模型（可选） |
业务领域分解 |
领域，领域对象，聚合根 |
|
逻辑模型（必选） |
描述系统逻辑分解 |
系统、层、面、子系统、功能模块、逻辑接口 |
|
|
数据模型（强数据场景必选） |
描述系统数据分解及关系 |
数据实体，属性，数据关联关系 |
|
|
技术模型（必选） |
系统技术实现 |
技术元素（数据库、中间件、框架、平台等），逻辑元素的技术选型，基于技术方案产生的服务、组件等 |
表1. 用例视图和逻辑视图
1 用例视图
1.1 上下文模型
1) 核心关注点：系统边界，外部环境。
2) 操作要点：
i. 上下文模型描述系统和外部环境（包括人、系统及外部实体）之间的关系，依赖和交互。通过上下文模型，可以显式的定义系统的范围、职责、边界。
ii. 上下文是领域模型建立的基础，该上下文不涉及技术，旨在从业务的角度划分系统的边界，澄清和周边业务系统的关系。
iii. 可用习惯的图示方式或采用UML语言的方式创建上下文图，描述领域的边界及外部角色，并通过文字描述系统与外部角色之间的约束、配套关系等。
3) 从领域模型输出上下文模型：
领域模型中，决策者分为用户角色、定时器、外部系统（外部第三方系统、内部周边系统），它们即是上下文模型中的外部依赖。另外，决策者触发的决策命令，以及决策命令触发的领域事件就是外部依赖的接口。所以我们从决策者、决策命令、领域事件这些元素就能梳理出上下文依赖关系图和依赖关系对应的接口，效果图见图5。
图5. 决策者在分析对象的依赖关系展示
下面我们看CS资产管理系统的上下文模型，见图6：。上下文的依赖关系可以从业务流模型中的决策命令获取，见图7，也可以从决策者依赖的聚合的方法中获取，见图8。
图6. CS资产管理系统上下文模型
图7. 业务流片段
图8. 区域聚合样例
1.2 用例模型
1) 关键用例
每个业务流概括出的名称就是该系统与外界的关键用例。下面看CS资产管理的案例，如：资产管理系统管理员梳理出二个业务流，其名称分别是的维护资产、导入资产；系统三方系统梳理出三个业务流，其名称分别是第三方的资产的同步、漏洞系统的资产的同步、第三方资产上报，它们生成的关键用例模型见图9。
图9. 资产管理系统关键用例（部分样例）
2) 交互场景
交互场景，是对于系统与外部实体之间的复杂交互关系的描述，以帮助描述隐含的需求和约束，及系统验证。
其实，它是和多彩领域建模的业务流有异曲同工之妙。多彩领域建模的业务流按按场景、时间顺序体现了外部实体与本系统的交互，只是两种展示的形式。
下面我们以CS资产管理系统为例，来看看两种展现形式：
图10. 维护资产的业务流形式
图11. 维护资产的时序图形式
2 逻辑视图
2.1 领域模型
应用多彩领域建模方法，直接的交付件就是领域模型。它分两部分：战略和战术模型。
1) 战略模型
下面我们以CS资产管理系统的战略模型为例，见图12。
图12. CS资产管理系统战略模型
2) 战术模型
下面我们以CS资产管理系统的资产管理上下文为例看看战术模型，见图13。
图13. CS资产管理系统的资产管理上下文战术模型
1.1 逻辑模型
根据上下文、聚合可以确定系统内部模块/组件/服务/微服务，根据它们之间的组成或者依赖关系即可形成逻辑模型。下面以资产管理系统战略模型为例转换成逻辑模型，见图14。逻辑模型是分层的，如资产管理内部又分成资产和区域两个模块，这就是2级模型，以些类推。
图14. 资产管理系统的逻辑模型
1.2 数据模型
可以用领域建模战略建模的聚合进行数据设计，定义关键的数据实体及相互关系。静态数据结构模型可使用实体-关系图（E-R图）或UML类图创建静态数据结构模型。下面我们用类图的方式看看CS资产管理系统的数据模型图，见图15。
图15. CS资产管理系统的数据模型图（类图样例—战略模型）
也可能通过领域建模的战术模型的聚合根、实体、值对象来输出数据模块，见图16。
图16. CS资产管理系统的数据模型图（类图样例—战术模型）
1.3 技术模型
技术模型中的架构元素，通常包括数据库、中间件、框架、平台等通用技术元素，以及对逻辑模型进行方案设计后形成的服务、组件等技术元素。技术模型在逻辑模型的基础上，补齐了技术方案和技术部件。技术模型中的最小技术元素，与对应的逻辑模型一样，同样为服务或组件。
领域模型中的上下文、聚合边界，可用来划分模块，而得到模块后根据业务上的需要可以衍生出组件、服务、微服务等，见图17。
图17. 模块、组件、插件、服务/微服务的有关系
模块划分后，我们可以针对每个模块确定他的技术模型，以资产管理系统的资产管理上下文对应的资产管理模块设计为例，看看它需要的技术元素如下：(见图18)
框架：第三平台数据同步框架、跨组件消息变更框架、Spring…
平台：权限管理…
数据库：高斯DB…
中间件：JPA+Hibernate…
………
图18. 模块、组件、插件、服务/微服务的有关系
总结
多彩的领域建模是一种设计方法，4+1视图是一种标准的架构展现形式，它们架构设计共同核心是场景视图和逻辑视图。分别通过人人精通模块设计系列精品课程—《多彩的领域建模战略设计》、《多彩的领域建模战术设计》承载。目前，这些能力已经在北研、上研、西研20多个基层团队同步应用，广受好评。下面是我们阶段成果交流会总结：链接》