TechRoad_Architecture_Design_DDD

目的：修炼架构设计内功--- Domain Model, Domain Object

-----

《DDD implementation》   Chapter3 P97

1. 处理资源不可用的一个好办法便是将其显现出来。标准类型实现状态(state)模式， 此时状态是一个值对象。

不同上下文集成,可基于 REST, 或是 消息机制，如RabbitMQ.

不应该将重点放在技术实现或是集成产品上，应该放在限界上下文之间的分离上.可以保持每个上下文的纯洁性，同时将一个上下文中的

数据用在另一个上下文的概念中。

关注系统的自治性。

在使用领域事件和事件驱动架构(Event-Driven Architecture) 仔细思考最终一致性(Eventual Consistency) 

远程完成创建，支持哪种类型的通信方式：

RPC,如果远程的CollabOvation系统不可用，ProjectOvation将定期重试直到成功为止.

如果采用消息机制，ProjectOvation将向CollabOvation发出消息，在资源创建成功之后，CollabOvation同样会以消息的形式返回。

当ProjectOvation接收到返回的消息时，将使用新建Discussion的标识引用来更新本地的Product对象。

接收到了远程数据，ProjectOvation 将使用异步组件--不管是RPC客户端还是消息处理器-来调用Product的 attachDiscussion()方法，

传入的参数为一个新创建的Discussion值对象。所有依赖于远程资源的本地聚合都会通过这种方式来处理。

---

2021-05-06

领域事件：

对不同的事件进行定义。

将领域事件建模成对象，

将领域中所发生的活动建模成一系列的离散事件。每个事件都用领域对象来表示.....领域事件是领域模型的组成部分，表示领域中所发生的事情。

有时是因为领域事件需要发布到外部系统中，比如发布到另一个限界上下文中。

将 platform performance 中的 

1. 数据解析

2. 数据清洗

3. 分类数据

4. 可进一步process 的数据进行 regression 对比。 

---

领域事件并不由聚合中的命令方法产生，而是直接由客户方所发出的请求产生，此时，领域事件可以建模成一个聚合，且可以拥有自己的资源库。

要成为模型结构的一部分，应该设计成不变的，它们将拥有唯一标识。最好 采用生成的唯一标识。

---

一种简单高效的发布领域事件的方法便是使用 观察者（observer ) 模式，可以在领域模型和外部组件之间进行解耦。

应用服务则是领域模型额直接客户。

p262   发布与订阅。

---

2021-05-07

在DDD中，支持 最终一致性的实用方法： 即一个聚合 的命令方法所发布的领域事件及时地发送给异步的订阅方：  p327

是否由执行该用例的用户来保证数据的一致性。如果是，则使用事务一致性 . 当然此时依然需要遵循其他聚合原则。

如果需要其他用户或者系统来保证数据一致性，请使用最终一致性.

真正的系统不变性条件：那些必须 使用事务一致性的不变条件。

---