领域驱动设计的核心是模型驱动设计，而模型驱动设计的核心又是领域模型，领域模型必须在统一语言的指导下获得。领域模型又可进一步细分为核心子领域、通用子领域和支撑子域。
系统上下文、限界上下文、分层架构和聚合都属于领域驱动设计的边界控制手段，他们的区别在于对业务划分的粒度和维度不同。
领域驱动设计统一过程
“人类是通过在问题空间中寻找解决方案来解决问题的”
同理，软件系统的构建实则是对问题空间的求解，以获得构成解空间的设计方案。
问题空间强调通过统一语言来描述需求问题，利用核心子领域、通用子领域和支撑子领域来分解问题空间。
解空间中，这些子领域将被映射到限界上下文，可以根据子领域类型的不同为限界上下文选择不同的建模方式。比如核心子领域可以选用领域建模，而支撑子领域的限界上下文可以选择事务脚本模式
注意：由此可见，子领域是问题空间中的概念，在拆分问题时，对问题进行分级；限界上下文是解空间中的概念，它跟问题空间中的子领域具有映射关系，可以基于子领域推导出限界上下文来
在限界上下文中要通过分层架构将领域模型独立出来，其目的是实现关注点分离，比如通过分层架构将技术与业务分离，保持两者的变化仅在其所在的层次内传递，防止两者复杂度的交织引发的更大范围的复杂度。
领域驱动设计战略设计阶段的核心模式是限界上下文，指导架构设计的核心模式是分层架构，前者决定了业务架构和应用架构，后者决定了技术架构。
领域驱动设计的核心诉求是让业务架构和应用架构形成绑定关系，同时降低与技术架构的耦合，使得在面对需求变化时，应用架构能够适应业务架构的调整，并隔离业务复杂度与技术复杂度，满足架构的演进性。
完整的领域驱动设计过程划分为三个重要的阶段：
1）全局分析阶段：对现实世界中问题的分析
2）架构映射阶段：解决现实世界与软件解决方案的桥接问题
3）领域建模阶段：对软件解决方案内部进行进一步的分析建模
全局分析阶段
目标：通过可视化的手段完成对问题空间的探索与分析
任务：通过执行价值需求分析和业务需求分析活动，深入剖析问题空间
活动：价值需求分析、业务需求分析
产物：全局分析规格说明书
价值需求分析
价值需求分析
利益相关者、系统愿景和系统范围共同组成了目标系统的价值需求，分属于 5W 模型中的 Who、Why 和 Where。
首先需要识别出目标系统的利益相关者（Who）
然后通过统一利益相关者的业务目标，明确目标系统的界限和方向
最终做到明确系统愿景（Why）和识别系统范围（Where）
模式：统一语言
方法：商业模式画布
利益相关者
支持者，比如组织、部门、员工和上游第三方合作伙伴
受益者，比如用户、下游第三方
注：上游指的是提供价值方，下游指消费价值方。
业务需求分析
价值需求分析指导业务需求分析。
业务需求由动态业务流程和静态的业务场景、业务服务组成，两者的结合依靠业务场景按照时间点和业务目标对业务流程进行拆分。
业务需求分析阶段可分三个层级对业务需求进行逐级的问题拆解，如下。完成问题拆解后，即可梳理出核心子领域、通用子领域和支撑子领域。
第一层：业务流程
第二层：业务场景
第三层：业务服务
模式：统一语言、核心子领域、通用子领域、支撑子领域
可视化方法：业务流程图、服务蓝图、业务服务图、事件风暴
业务流程
第一层级，在业务目标指导下梳理出提供业务价值的动态业务流程。属于 5W 模型中的 When。
业务流程的起点往往由一个角色想目标系统发起服务请求，而要完成整个流程，则需要多个角色共同参与协作。业务流程的特点是：1）具有时间属性 2）多角色参与 3）输出业务价值
识别业务流程的两个关键点是：完整和边界。完整是指要具有端到端的完整协作过程，体现一个完整的业务价值；边界仍然是从业务价值层面确定业务的范畴。
可视化方案：业务流程图、服务蓝图
业务场景
场景就是角色之间为了实现共同的业务目标进行互动的时空背景，通过角色在特定时间、空间内执行的活动来推动情景的发展，形成角色与目标系统之间的体验与互动
第二层级，按照时间对业务流程进行切分，划分出每个时间阶段的业务场景，每个业务场景时可以由多个角色参与的。
业务流程与业务场景的区别与联系
一个动态的业务流程是由一到多个静态的业务场景构成的，业务流程是端到端的完整协作过程，业务场景则是在业务目标的指导下在时间维度对业务流程的纵向切分。
可视化方案：用例图，例如：
业务服务
第三个层级，每个角色在业务场景下的一次功能性交互形成业务服务。业务服务是全局分析阶段的基本业务单元。属于 5W 模型中的 What。1）提供了目标系统的核心价值，满足了利益相关者的价值需求的业务服务，归入核心子领域 2）属于业务需求一部分，但是横向支撑了多个领域服务，不具有明显的个性特征的业务服务，则归入通用子领域 3）起支撑和辅助价值的业务服务，归入支撑子领域
架构映射阶段
分别从组织级、业务级和系统级三个层次完成对问题空间的求解，然后将其映射为架构层面的解决方案。这一步可以基于 C4 图的第一层来表示。
组织级映射
目标是确定系统上下文。根据价值需求分析的结果，通过系统上下文呈现利益相关者、目标系统与伴生系统之间的关系。
模式：系统上下文
方法：系统上下文图、业务序列图
业务级映射
目标是确定限界上下文。根据业务需求分析的结果，对相关的业务服务进行归纳和分类，形成限界上下文。限界上下文内部采用菱形对称架构模式组织业务数据 &服务，限界上下文之间采用限界上下文映射模式解决它们之间的协作问题。
设计限界上下文的四要素：最小完备、自我履行、稳定空间、独立进化
模式：限界上下文、上下文映射和菱形对称架构
方法：V 型映射过程、事件风暴、服务序列图、康威定律、领域特性团队
限界上下文映射模式
领域模型需要通过限界上线文来限定业务的自治边界，限界上下文之间也需要通过各种方式进行协助，那么根据不同的协作方式，上下文映射关系可以划分为以下 8 中模式：
客户方/供应方
共享内核
遵奉者
分离方式
开放主机服务
发布语言
防腐层
大泥球
系统级映射
目标是建立分层架构。分层架构位于系统上下文内部，可考虑如下分层
模式：核心子领域、通用子领域、支撑子领域、系统分层架构
方法：康威定律
领域建模阶段
目标是在限界上下文内部建立领域模型。
领域建模可分为领域分析建模、领域设计建模和领域实现建模。
领域分析建模
在统一语言的指导下，通过快速建模法对业务服务进行提炼和抽象，获得领域分析模型。
快速建模法是对“名次动词法”的丰富和补充，建立了标准化的领域分析建模过程，它分为如下四个步骤：
名词建模：识别业务服务规约中的名词。名词代表了候选对象，可将其映射为领域模型对象。
动词建模：识别业务服务规约中的动词。动词代表了候选对象上的候选操作，可将其映射为领域行为，若领域行为产生了过程数据（比如单据或交易记录等），则将该过程数据识别为领域概念。
归纳抽象：针对有定语修饰的领域概念进行归纳和抽象。
确定关系：确定领域概念之间的关系。
下面是最终产出的领域分析模型示意图：
产出是业务服务规约和领域模型概念图。
模式：统一语言、限界上下文、模型驱动设计
方法：快速建模法、事件风暴
领域设计建模
对完整业务服务展开设计工作，获得领域设计模型。
产出：以聚合为核心的静态设计类图和由角色构造型组成的动态序列图与序列图脚本。
方法：角色构造型、服务驱动设计
领域模型的设计要素
实体：一个典型的实体应该具备身份标识、属性和领域行为这 3 个基本要素，符合信息专家模式，避免贫血模型。
值对象：不需要被追踪且是不可变的，通常作为实体的属性。
聚合：聚合是介于限界上下文和类之间的一个封装层次，它是边界而不是对象，边界内保证对象的一致性和完整性，对外作为一个整体参与业务行为的协作。
领域服务：如果领域行为是无状态的，或者需要多个聚合的协作，又或者需要访问外部资源，则应该将它分配给领域服务。
领域事件：主要用于表达领域对象状态的迁移，也可以通过事件来实现聚合乃至限界上线文之间的状态通知。
模式：统一语言、模型驱动设计、实体、值对象等 DDD 基本设计元素
资源库：资源库是对数据访问的一种业务抽象，它分离了聚合的领域行为和持久化行为，保证了领域模型对象的业务纯粹性。
工厂：管理聚合的创建过程。
领域实现建模
基于 TDD 完成代码设计和单测编写，获得领域实现模型。
产出是实现业务功能的产品代码和验证业务功能的测试代码。
模式：统一语言、模型驱动设计
方法：测试驱动开发、简单设计、测试金字塔
END
架构师交流群
「架构君」建立了读者架构师交流群，大家可以添加小编微信进行加群。欢迎有想法、乐于分享的朋友们一起交流学习。
扫描添加好友邀你进架构师群，加我时注明【姓名+公司+职位】
强势开源一款小程序！
2021-11-07
强力推荐一个完善的物流（WMS）管理项目（附代码）
2021-10-23
推荐一个 Spring Boot + MyBatis + Vue 音乐网站
2021-10-19
分享一套家庭理财系统（附源码）
2021-09-20
推荐一个互联网企业级别的开源支付系统
2021-09-04
推荐一套开源通用后台管理系统（附源码）
2021-08-21
一款神仙接私活儿软件，吊到不行！
2021-07-31
基于 SpringBoot 的仿豆瓣平台【源码分享】
2021-07-18
干掉 Wordpress！这个开源建站神器有点吊！
2021-06-18
从朋友那里搞了 20 个实战项目，速领！
2021-06-12
250
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
