ddd领域模型落地难

难以理解的概念

1：DDD 是一个很老的概念，但在我身边的技术圈，这仍然是个常常被提起的词。不过1.1：很多人在谈论这个概念，但很少有人说清楚，并给出详细具体的实践指导

2：思维的转变

2.1：DD要求我们根据产品原型建模，识别领域、限界上下文、子域，这些需要时间思考的问题就像一座座大山，让我们望而却步。且由于项目前期看不到DDD带来的高效，反而没那么敏捷了，并且前期的建模还可能要推倒重来，这让更多人一开始就想放弃，而只有随着需求的不断迭代，DDD才会显示出它的优势。

3：业务划分限界上下文

3.1：限界上下文是业务概念的边界，是业务问题最小粒度的划分。在OTO探店业务领域中会包含多个限界上下文，我们通过找出这些确定的限界上下文对系统进行解耦，要求每一个限界上下文其内部必须是紧密组织的、职责明确的、具有较高的内聚性

4: 领域实体模型

失血模型：模型仅仅包含数据的定义和getter/setter方法，业务逻辑和应用逻辑都放到服务层中。这种类在Java中叫POJO。
贫血模型：贫血模型中包含了一些业务逻辑，但不包含依赖持久层的业务逻辑。这部分依赖于持久层的业务逻辑将会放到服务层中。
充血模型：充血模型中包含了所有的业务逻辑，包括依赖于持久层的业务逻辑。
胀血模型：胀血模型就是把和业务逻辑不想关的其他应用逻辑（如授权、事务等）都放到领域模型中

5：领域之间通信

5.1：领域事件-通过kafka等实现

6：领域事件带来的缺点

6.1：业务上下游之间，变成了，下游的领域，需要去接受上游的业务事件，并且做各种补偿，稍有问题，会导致整个业务流程中，上下游的数据不一致，这样的解耦方式，并没有给整体的业务系统带来优势，只是把之前上游需要关注的事情转嫁到了下游，并且把整个流程做的复杂。

7：领域模型的未来

7.1：需要做到，各个领域之间，区分出来，域对象，域业务功能模型，域功能，三个维度的数据，各个域之间，没有任何交互，也没有事件等通知。（详细了解spider-node）
7.2：需要引入编排，，编排的域功能形成域的业务功能。这样子来弥补事件驱动，与现在的领域模型实现上带来的缺点，和提高落地性。并且能快速看到效果。(详细了解spider-node)

spider-node

spider层面提供解决领域模型的难落地
添加链接描述