cosmic_python

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

参考资料


版权声明:本文为qq_18122705原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。