DDD整体架构

领域建模

领域模型

• 领域：即你要解决的问题，核心需求。比如“购买一个商品”、“生产一个商品”等
• 模型：对于某个过程或现象的抽象。比如说用“电压 = 电流 X 电阻”这个欧姆定律来描述电阻上的电流和电压的规律。
• 一个领域模型包含：Entity、Value Object和Service。
  • Entity和VO都是具体的业务对象。
  • Entity（实体）：具有特定‘标识’的对象，关注的是其标识，即使它的属性有所改变，它仍是原来的对象。
  • Value Object（值对象）：一个包含属性的对象，更关注其不变的属性，当属性改变时，就是一个新的VO了。
  • Service（业务操作）：与controller-service-dao中的service层含义不一样。这里的service描述的是一个以本领域模型为边界的过程。而service层中的service 层描述的是一个用例，service层会调用领域模型中的业务操作。
    • 这些业务操作没有必要上升成为一个对象，比如说FooManager、BarBuilder等，完全可以用manage_foo, bulid_bar来描述（当然用Java这种纯OOP的语言另说）。

Repository模型

• 出现动机：希望存储能与领域模型分离开，领域模型不依赖底层存储的选择
• 其实Repository层与Java三层中的DAO层的不同点在于，DAO模型往往被看作应用和DB之间网关，从而习惯性地将所有与DB的交互都放在同一个DAO类中，导致DAO过于肥大。而Repository则更倾向于作为一个“数据集合”开放给上层，提供最原始的CRUD。参考Don’t use DAO, use Repository

• 如果业务只是简单的CRUD，其实没必要强行上DDD

参考资料

• Repository