DDD实战课（1）：基础篇

课程学习链接

https://time.geekbang.org/column/article/149941

引子

DDD 、微服务与中台设计的结合，还有很多难题等待攻克：业务领域边界划分，中台领域建模以实现能力复用、单体应用重构与微服务设计、前中后台的协同设计等等。

主要关注：采用领域驱动设计（DDD）实现中台业务建模，专注基于 DDD 的微服务设计和开发。

开篇词

DDD、微服务和中台之间的关系：中台本质是业务模型，微服务是业务模型的系统落地/技术手段，DDD 是一种设计思想，同时指导中台业务建模和微服务设计。

DDD 强调领域模型和微服务设计的一体性，先有领域模型然后才有微服务。DDD指导下的中台设计思路：通过战略设计，借助通用语言建立领域模型，划分微服务边界；通过战术设计，从领域模型转向微服务设计和落地。

基础篇：DDD核心知识体系（重点）

01 | 微服务设计为什么要选择DDD？DDD与微服务基本介绍

背景：软件架构模式的演进

软件架构模式的演进

（略）第一阶段是单机架构：面向过程的设计方法，系统包括客户端 UI 层和数据库两层，采用 C/S 架构模式，整个系统围绕数据库驱动设计和开发，并且总是从设计数据库和字段开始。

第二阶段是集中式架构：面向对象的设计方法，系统包括业务接入层、业务逻辑层和数据库层，采用经典的三层架构，也有部分应用采用传统的 SOA 架构。这种架构容易使系统变得臃肿，可扩展性和弹性伸缩性差——由于业务逻辑全部集中在业务逻辑层导致。

第三阶段是分布式微服务架构：微服务架构可以很好地实现应用之间的解耦，解决单体应用扩展性和弹性伸缩能力不足的问题。

微服务设计和拆分的困境

微服务最尖锐的一个问题是：“微服务到底怎么拆分和设计才算合理，拆多小才叫微服务？”DDD思想就用于解决这个问题。

微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。
DDD 核心思想就是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

什么是DDD

DDD 是一种处理高度复杂领域的设计思想，围绕业务概念构建领域模型来控制业务的复杂性，保证业务模型与代码模型的一致性，以解决软件难以理解、难以演进的问题。
DDD 不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，同时通过战术设计，借助分层架构，可以很容易地实现架构演进与服务之间的解耦。

DDD 包括战略设计和战术设计两部分：战略设计完成领域建模划分边界，战术设计完成微服务设计。具体为：
战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。
战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。

战略设计

战略设计建立领域模型，领域模型用于指导微服务的设计和拆分。
主要手段：事件风暴。
采用用例分析、场景分析和用户旅程分析，尽可能全面不遗漏地分解业务领域，并梳理领域对象之间的关系，这是一个发散的过程。事件风暴过程会产生很多的实体、命令、事件等领域对象，我们将这些领域对象从不同的维度进行聚类，形成如聚合、限界上下文等边界，建立领域模型，这就是一个收敛的过程。

三步划定领域模型和微服务的边界
第一步：在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。
第二步：根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。在这个图里，聚合之间的边界是第一层边界，它们在同一个微服务实例中运行（位于同一个领域模