DDD工作坊笔记

1、判断是否是事件        

判断事件是否有影响的事件：是否产生了数据、是否发生状态变更、对内触发了什么流程、对外发送了什么消息（后面两个不一定产生事件）

• 事件去掉，业务是否能正常进行
• 查询、上传，没有事件。修改信息是有的
• 有无数据产生

2、子域划分

   （1）子域：具有同样价值的一组业务。（业务视角）    

   （2）子域名字起得抽象，很大原因是子域划分不合理，把所有东西融在一起，妄图用一个宽泛的概念包含住。

   （3）没有核心域业务就没有意义。支撑域支撑核心域，没有支撑域，核心域则无法工作。

   （4）核心域、通用域、支撑域的划分

      中台看起来可有可无，前台必须要有，也要做，且不是通用域。

      优先级高低（业务价值的高低）。随业务发展，核心优先级不同。开始建设——功能更重要，运营（大数据）——数据分析变得重要。核心域随之而变。

      核心竞争力，战略价值高，希望做大做强，建议核心域。（回到elevator speech，找愿景）

3、战术设计——解决问题

（1）限界上下文（解空间）

• 问题边界（可以和子域边界一致）
• 变化一致性（生命周期）
• 变化频率
• 弹性一致性（普通下订单、秒杀下订单弹性边界不一样，业务边界很像）
• 业务维护不一致（组织上差异）
• ……

        需要确定限界上下文与子域是否边界一致，是则一对一。可以一个子域对多个解空间（多个解决方案，解决一个问题。）。反之则不行，是子域没划分好。

（2）找依赖关系——检查上下文划分是否合理

A——>B ：A依赖B。被依赖的是上游。

        检查关系是否成环，互相依赖有问题，可能是同一个上下文。 形成依赖环也有问题。

（3）领域模型——聚合根、实体、值（静态）

        一个限界上下文只有一个聚合，则它就是聚合根。 检查事件上的事情是否都体现在聚合上。

        尽量让一个（领域）对象薄一些，不超过20个字段。 尤其是聚合根，一般特别大。（有时候一个聚合就是一个微服务）

        在一个上下文中去聊实体和值对象

实体：

有主键id。

有完整的生命周期，创建、修改、销毁。

判断是否相同比ID

值：

只读

用完就释放（即用即弃，没有生命周期）。

判断是否相同，比所有属性的值。

起描述作用（描述实体——依附于实体）

实体、值（对象）都是class，只是在new实体时，自动set值对象。

持久化方式，数据库、redis、内存都需要领域对象；如果是IO流读取，则不需要领域对象。

多对多的关系表示不了，需要一个中间对象。

（4）API设计

• GET（SELECT）：从服务器取出资源（一项或多项）。
• POST（CREATE）：在服务器新建一个资源（新增）。
• PUT（UPDATE）：在服务器更新资源（覆盖）。
• DELETE（DELETE）：从服务器删除资源。

一般而言接口设计避免设计万能接口。

如：“修改”概念太广，不好控制。update可以细化为update-info