DDD序列1-概念篇

引言

近年来，中台和微服务架构如火如荼，特别是微服务已经成为了业内事实上的架构标准，做为一个IT从业人员如果还不了解微服务，那你需要再多多努力了。

虽然了解微服务的人很多，但能够设计好微服务的人并不多。比如说微服务是怎么拆分的？为什么要拆分成这几个微服务？这些服务之间的边界和范围是怎么界定的？当一个新需求来了，应把它放在A服务去实现呢，还是放在B服务中去实现？等等这些问题是每个架构师经常会面临的问题。那么有经验的架构师会根据自己的经验和以前踩过的坑进行了设计，不同的架构师设计出来的结果可能是千差万别的。那么有没有一套理论体系和方法论可以我们去进行微服务设计呢？有什么准则和规范可以用以检验我们的微服务架构是否合理呢？答案是肯定的，它就是——DDD。

为什么DDD适合微服务

DDD 和微服务都是处理高度复杂领域的设计思想。DDD 解决复杂问题的过程，体现的是一种“分而治之”的思想。当我们遇到问题时，如果能力大于问题，直接用能力解决就可以了；而如果能力小于问题，则把问题进行拆分，直到问题小于能力为止。

DDD处理复杂问题的思路

DDD不是一种架构，它是一种架构设计方法论，是一种处理高度复杂领域的设计思想，它将业务复杂度和技术复杂度进行分离，它通过业务边界划分将复杂业务领域问题简单化，帮我们划分出清晰的业务领域和应用边界，从而可以很容易地实现微服务的架构演进。

DDD包括战略设计和战术设计两部分，它们分别从不同的视角出发，完成领域建模和微服务的拆分设计。

战略设计是从业务视度出发，划分业务的领域边界，建立限界上下文，构建领域模型。而限界上下文就可以作为微服务拆分和设计的边界。战术设计则是从技术的角度出发，侧重于对领域模型的技术实现，按照领域模型完成微服务的开发和落地。在战术设计的过程中会产生聚合、聚合根、实体、值对象、领域服务、领域事件、应用服务和仓储等领域对象，这些领域对象会以代码的形式映射到微服务中，完成设计和系统落地。

微服务整体设计过程

微服务的设计整体可以分为2大部分：战略设计和战术设计

DDD主要包括战略设计和战术设计

战略设计又包括2块：领域分解和领域建模；

战术设计也包括2块：微服务设计和详细设计及技术实现。

DDD设计的过程

战略设计

首先，针对业务领域，通过流程及功能分析、业务场景分析、用例分析和用户旅程分析等方法，尽可能地梳理业务领域，发现这些业务领域中的命令、领域事件、领域对象以及它们的业务行为，并梳理这些领域对象之间的关系，这是一个发散的过程。

然后，将事件风暴过程中提取的实体、值对象和聚合根等领域对象，从不同的维度进行聚类，形成如聚合上下文等边界，并在限界上下文边界内建立领域模型，这是一个收敛的过程，收敛输出的结果就是领域模型。

事件风暴是进行领域划分和领域建模的一个很重要且很实用的方法，但如果问题空间很大时不适合直接进行事件风暴，这时我们先把问题空间划分为三类子域：核心子域、通用子域和支撑子域。

核心子域：在企业内决定产品或企业核心竞争力的功能子域就是核心子域，它是让企业业务和商业模式成功的关键核心能力，是企业面对竞争对手时所拥有的核心竞争力。

通用子域：那些没有太多个性化的需求，同时又会被多个子域重复使用的通用功能子域是通用子域

支撑子域：那些子域是企业必需的，但它既不是决定产品或企业核心竞争力的功能，也不是被其他子域复用的通用功能，这类子域是支撑子域。

以保险业务为例，我们划分子域的结果如下：

领域划分为核心子域、通用子域和支撑子域

通过领域划分，区分不同子域在企业内的不同功能属性和重要性，使用企业可对不同子域采取不同的资源投入和建设策略。

将问题空间划分为三个子域后再在子域内进行事件风暴，在事件风暴过程中，领域专家、架构师、产品经理、开发工程师、测试工程师一起通过用户旅程分析、业务场景分析，提取出业务领域中的所有领域对象，将这些对象进行聚合，并划定业务边界，然后建立领域模型。

DDD领域分析和设计过程

小结

本文主要讨论了使用的DDD进行微服务设计的大概流程，其中涉及到了领域分解、领域建模、事件风暴、战略设计、战术设计、限界上下文、核心子域、通用子域、支撑子域、领域对象、聚合、聚合根等概念，DDD的概念确实比较多，刚开始笔者看这么多概念也比较困惑，后来慢慢地才理解了它们的含义。读者如果记不住这么多概念，那你只要记住了战略设计、战术设计和事件风暴这三个概念就算是有了收获了，后面的序列文章会对其他的概念进一步的讲解。

本文只对战略设计的方法进行了讲解，战术设计的方法会在下一篇文章中进行讲解。

DDD比较强调统一语言，这部分内容我们也会在后续的文章中进行介绍，敬请期待。

声明：本文是笔者学习《中台架构与设计：基于 DDD 和微服务》一书时，按照自己的理解整理的笔记，文中的大部分内容和插图来自于原著，特些声明。