DDD领域驱动设计
2004年，Eric Evans 出版了《领域驱动设计》一书，提出了针对业务领域建模的方法论和思想 - Domain Driven Design，简称DDD。DDD的核心思想，是从业务视角出发，根据限界上下文划分业务的领域边界，定义领域模型，确定业务边界。在微服务落地时，建立业务领域模型与微服务代码模型的映射，从而保证业务架构与微服务架构的一致性。
DDD是一种处理高度复杂领域的设计思想。DDD提出了一套核心构造块，如聚合、实体、值对象、领域服务、领域工厂、仓储、领域事件等。这些构造块是面向对象领域建模的最佳实践和标准。利用DDD分层架构、六边形、洋葱型等架构，可以达到分离业务复杂度和技术复杂度，让系统具备更强的扩展性和弹性。
DDD战略设计
从业务视角出发，划分业务的领域边界，建立基于通用语言和业务上下文语义边界的限界上下文，构建领域模型。而限界上下文就可以作为微服务拆分和设计的边界。领域的战略设计中的领域建模是一个从发散到收敛的过程，通常采用事件风暴工作坊方法。
事件风暴工作坊方法
针对业务领域，通过用例分析、场景分析和用户旅程分析等方法，尽可能全面地、不遗漏地梳理业务领域，发现这些业务领域中的命令、领域事件、领域对象以及他们的业务行为，并梳理出这些领域对象之间的关系，这是一个发散的过程。
-
我们将实现风暴过程中提取的实体、值对象和聚合根等领域对象，从不同的维度进行聚类，形成如聚合和限界上下文等边界，并在限界上下文边界内建立领域模型，这是一个收敛的过程。收敛输出的结果就是领域模型。如图：
领域的限界上下文和聚合边界
DDD战术设计
从技术视角出发，侧重于领域模型的技术实现，按照领域模型完成微服务的开发和落地。战术设计会有聚合、聚合根、实体、值对象、领域服务、领域事件、应用服务和仓储等领域对象，这些领域对象以代码的形式映射到微服务中，完成设计和系统落地。
采用DDD设计的缺点
- 对开发人员要求相对较高，实现起来会有一定的复杂度
采用DDD设计的优点
- DDD是一套完整而系统的设计方法论，规范设计思路和设计过程，形成一套统一的开发设计标准
- DDD通过分治策略降低业务和系统建设的复杂度，建立稳定的领域模型，处理高度复杂业务领域的软件开发
- DDD领域建模，强调沟通合作，建立团队通用语言
- DDD设计有聚合、有边界，容易进行微服务拆分和系统重构
DDD、微服务、中台的关系
DDD是一种架构设计方法论，通过业务边界划分将复杂业务领域简单化，划分出清晰的业务领域和应用边界，从而很容易的实现微服务的架构演进。DDD将子域划分为核心子域、通用子域和支撑子域，目的是识别企业重点领域，有区别地确定战略资源的投入，投入重点自然是核心子域。我们看下DDD视角与中台视角的对应关系，如下图所示：
中台设计偏向于业务架构，形成中台的过程也是业务领域不断细分和能力沉淀的过程，在这个过程中，我们会对同类通用业务能力进行聚合和重构，再根据限界上下文和业务内聚的原则建立领域模型。DDD战略设计最擅长的就是领域建模。在完成中台的领域建模后，领域模型就可以作为微服务设计的输入。限界上下文和领域模型可以作为微服务拆分和设计的边界和依据。如下图所示：
因此，业务中台和微服务是DDD实战的最佳场景。
