如何使用DDD分析一个项目
1. DDD简介
DDD及Domain Drive Design（领域驱动设计），它力求将一个复杂的大型项目拆分成若干个内容相对独立的小项目，以降低开发难度，加速开发速度，最终可以按照业务领域将一个Allinone的大型系统拆解为一个分布式的系统。
DDD自上而下可以分为领域、界限上下文、领域服务、聚合根、聚合、实体、值对象。
- 领域：领域是DDD中最大的概念，领域是确定业务边界的技术体现，系统开发时最终会映射为业务群或独立服务，领域按照业务需求又可分为核心域（业务核心逻辑）、通用域（可复用公共能力）、支撑域（继承支撑能力）。
- 界限上下文：主要用来确定业务领域边界，界限上下文应由领域专家或架构师跟进行业经验来确定，界限上下文决定了领域的高内聚划分和最终架构设计方案，反过来，领域划分的是否合理也衡量了界限上下文的合理性。
- 领域服务：为上层建筑提供本领域对象的操作接口，负责对领域对象进行调度和封装，到这里，领域服务已经可以映射为一个微服务了，一个领域可以包含若干个领域服务，同样一个领域服务也可以包含若干个领域。
- 聚合根：聚合根是一个领域中最主要的领域对象，聚合根可以关联领域中的所有聚合、实体和值对象，在数据建模时聚合根可以映射为一张数据表。
- 聚合：一个聚合根中可以包含若干个聚合，每个聚合可以看作领域中的一个子领域。
- 实体：是最小的领域对象，它已经是一张不可再分割的数据表了。
- 值对象：是实体中相对不变的属性的集合，只有数据初始化操作和极少数的修改操作会变更它，它的变更不应包含任何业务的逻辑，如用户表中的暱称、性别等。
按照以上拆解步骤，DDD建模分析有一套相对固定的分析过程，总结为三板斧：
- 领域建模
- 领域和聚合根划分
- 聚合、实体和值对象划分
2. DDD建模三板斧
下面用一个例子来解释三板斧怎么进行DDD建模：
举一个非常老套的例子，一句话需求：我要建一个B2C的电商平台。
-
第一板斧：领域建模
第一步：明确需求，通过和产品经理扯皮得出，我要建一个电商平台，我可以往里面添加商品，用户可以购买我的商品。到这里电商平台的大基调基本确定，这个平台得有用户、商品、订单。
第二部：集中讨论，也就是所谓的事件风暴，一个大白墙，几个马克笔，一沓贴纸，大家畅所欲言，就如下图所示。
![]()
事件风暴的大体思路是：先将需求分解为一个一个的动作（这个动作就是领域事件），再根据动作分析动作的作用对象，形成一个领域对象和领域事件的关系聚合。
根据领域模型，我们可以分析出系统大模块总共分几个部分，每个部分的核心领域对象是什么，同时根据这个高内聚的领域对象分布，我们很直关的就能归纳出一个实用性的领域划分，如图所示，我们可以简单的将系统分为用户领域、商品领域和订单领域，同时也能分析出，系统的核心域（订单域、商品域）、通用域和支撑域（用户域）。
![]()
-
第二板斧：领域服务和聚合根划分
根据第一板斧的领域建模，我们可以得出一个简单的领域模型，并根据这个领域模型进行了初步的领域划分，到这里，大家可以看到领域模型离项目落地还差了好多，系统有了骨架，接下来填充血肉，我们要对领域模型进行需求细节填充。
按照经验，用户域应该包含详细信息、收货地址、SSO等，商品域应包括详细信息、SPU/SKU、供应商信息、品牌信息、商品图片等，订单应包括订单详情、订单生命周期、收货信息、商品评价等，最后形成一个比较详细的领域模型网状图。
![]()
-
第三板斧：聚合、实体和值对象划分
领域模型网状图画出来之后，我们可以大致看出来整个系统的数据分布和领域划分，接下来我们继续细化，细化分为两步：
- 把每一个子领域模型的具体属性补充进去。
- 思考每一个聚合是否还有拆分的必要，如有必要则拆分为实体和值对象。
到这里我们就可以得到一张非常具体的数据库ER图，接下来可以根据这个ER图进行具体的微服务划分和数据建模。
![]()
3. DDD和数据驱动设计
数据驱动设计一般是先分析需求，提炼ER图，ER图提炼出来之后主要的设计工作就已经完成。
领域驱动设计是一个自上而下的过程，一般是从总体出发，先站在全局视角，分析业务领域和聚合根，划分出核心域、通用域和支撑域，然后逐一分析子领域中的领域事件和数据聚合关系，搭建领域模型骨架，最后填充实体和值对象，形成一个个高内聚低耦合的领域模型。
然而在笔者看来，DDD和数据驱动设计并不是相互独立的，在做DDD建模时，当我们拆分子领域完成后，在做子领域的数据建模时实际也是用户数据驱动设计方法。
先使用DDD划分子领域，再使用数据驱动设计进行数据建模。
4. DDD和微服务的关系
微服务是一种分布式的技术架构模式，它主要是把一个大型的单体应用拆分成一个一个的独立微小服务，微小服务间相互协调，共同支撑一个大系统的运行。
DDD根据界限上下文划分出领域模型和领域服务，本身就可以实例化成一个个的微服务，通过领域驱动设计分析的系统天然支持微服务框架。
5. 写在最后
架构设计方法论千千万，DDD、数据驱动设计、MVC、N层架构、六边形架构，适合自己的才是最好的。
笔者一般做架构设计的习惯是：
- 先用DDD思想给系统划分领域。
- 再用数据驱动设计提炼ER图。
- 最后考虑业务场景确定工程代码结构和分层结构。