DDD落地方案

1.从领域到子域

领域与子域是DDD中的抽象概念，刚接触时如果过分深究其含义，很容易被其迷惑，举个简单例子理解下：你公司是做电商的，那电商就是你公司的领域，但是如果你领导跟你说我们要搞电商系统，你知道咋做吗？显然有点蒙，为什么？范围太大，问题不明确。这时候我们要对电商这个领域进一步细化，比如电商分为订单、商品、物流模块，那订单、商品、物流就属于电商领域下的子域，依然抽象，但更具体了，也更容易进行方案实施了，子域依然可以进一步细分为子子域，直到你觉得够具体了，就可以进行下一步的战略设计了。领域到子域的细分只是为了更具体化我们面对的问题，更方便实施解决方案

2.从问题域到解决方案域

DDD作为一种架构方法，最大的突破应该说是非常明确地区分出了问题域和解决方案域

我们提到领域和子域的划分是为了细分我们需要解决的问题，直到细分到我们可以实施解决方案，在此之前，一直属于问题域，在此之后，属于解决方案域，我们的方案在此展开。这很符合软件开发的思维，先分解问题，再解决问题

 

3.通过 事件风暴 帮助分析/解决问题

 

我们说了，子域划分到足够具体后，就应该从问题域转到解决方案域了，接下来要做的就是战略设计， 事件风暴是DDD进行战略设计 的主要方式，是一项团队活动，团队通过头脑风暴的形式罗列出领域中所有的领域事件，进而快速分析和分解复杂的业务领域， 完成 领域建模，事件风暴具体步骤如下：

0.产品愿景，搞清楚自己的定位：产品顶层价值设计，所有参与人员要对产品的目标用户，核心价值，竞争优势等信息达成一致，保证产品演进过程中不至于偏离方向

1.业务场景分析：站在用户的视角，采用用户旅程进行用例和场景的分析，参与者应尽量遍历所有业务细节，充分发表意见

2.提取实体、值对象：行为分析会产生许多命令以及事件，我们要从中提取实体以及值对象

3.识别聚合根，建立聚合：我们根据聚合根的管理性质，从实体中找出聚合根，以此发散，找出所有与其关联紧密的实体与值对象，形成聚合，聚合是DDD中的逻辑概念，是业务最小边界

4.划分限界上下文：我们根据上下文语义将聚合归类，形成一个个限界上下文，限界上下文是DDD中的逻辑概念，是聚合之上的一层边界

4.一些名词解释：

通用语言：在事件风暴的过程中，通过团队交流达成共识的，能够简明、清晰、准确的描述业务含义和规则的语言就是通用语言，通用语言包含术语和场景，能够直接反映到代码中，借助于通用语言，业务需求可以被准确转换为代码设计，代码的可读性更好

实体与值对象：实体有一个唯一的ID，除非ID相等，否则即使其他属性值都一样，也属于不同实体对象。具有一定的生命周期，会在生命周期中发生改变，但无论怎么变化，其ID始终不变，始终是原来的对象。值对象只是一组数据的组合，没有唯一标识，只要两个值对象的这组数据都相等，那这两个值对象就相等。本质上，实体对应的是看得见摸得着的实实在在的业务对象，有一定的属性以及业务逻辑，值对象只是包含了一组描述性属性的集合体，其依附于实体并对实体起描述作用

聚合：表示一组业务上密切相关的实体和值对象，聚合定义了高内聚和单一职责的业务与代码边界，在代码实现中，一个聚合往往对应了一个package

聚合根：每个聚合都会对应一个聚合根，聚合根首先是个实体，其次它作为聚合的管理者，在聚合内部负责管理实体和值对象的生命周期，协调实体和值对象按照固定的业务规则协同完成共同的业务逻辑

限界上下文：在设计好聚合后，我们会根据业务语义将一个或多个聚合归到一起，形成一个限界上下文，限界上下文是聚合之上的一层逻辑边界。它定义一个语义上的边界，保证在其中的通用语言语义的准确性和无二义性，定义了其中领域模型的适用范围，使团队成员明确什么可以在其中实现，什么不应该在其中实现。

5.准备开始战术设计

事件风暴后，我们已经提取出了业务涉及的所有实体、值对象、聚合根、实体间的关联关系，以及逻辑概念上的聚合、限界上下文。我们称这些内容为领域模型，是战略设计的成果

有了领域模型作指导， 战术设计就有了明确的方向 ，战术设计从技术视⻆出发， 侧重于领域模型的技术实现， 完成软件开发和落地，说白了就是怎么根据领域模型去实现代码，DDD推荐使用"DDD分层架构模型"来进行代码设计，基于此，下一篇中，我们将展开如何进行DDD代码层面的落地