DDD-落地实战 *

DDD 落地 #

基于DDD应用架构的核心 #

分离业务复杂度和技术复杂度

设计思路 [4] #

  • 贫血模型

    • 实现 业务逻辑放到Service中
    • 缺点 [7] 业务逻辑被埋没在存储业务中
    • 贫血模型的缺陷 [21]
      • 无法保护模型对象的完整性和一致性
      • 对象操作的可发现性极差
      • 代码逻辑重复
      • 代码的健壮性差
      • 强依赖底层实现
    • 99%的代码都是基于贫血模型 [21]
      • 数据库思维
      • 贫血模型“简单”
      • 脚本思维

  • 充血模型

    • 实现 业务逻辑放到领域对象中(实体对象中有实现方法)
    • 开闭原则 保持了对象的封装性，使得领域模型在面临多态、继承等复杂结构时，易于变更
    • 适用场景 类似继承、多态的情况 在软件设计的过程中需要将一些类型或者编码进行转换 更好地表现领域对象之间的关系 “聚合”，也就是在真实世界中那些代表整体与部分的事

  • 比较

    • 贫血模型比充血模型更加简单易行
      • 贫血模型 不需要 仓库、工厂、缓存，简单粗暴
    • 充血模型需要更强的设计与协作能力
      • 充血模型 需要开发人员有更强的OOA/D能力、分析业务、业务建模与设计能力 要有较强的团队协作能力
      • 贫血模型 所有业务处理过程都交给Service完成
    • 贫血模型更容易应对复杂的业务处理场景

分层 [2] #

  • 用户接口层(Controller层)
  • Application层
  • Domain层
  • Infrastructure层

代码分层 [2] #

  • Interface

    • assembler(DTO和领域对象的互转)
    • dto
    • facade（粗粒度的调用接口，将用户请求委派给一个或多个应用服务进行处理）

  • Application

    • event（pub， sub）（事件处理相关的核心业务逻辑在领域层实现）
    • service（应用服务）

  • Domain

    • aggregate
      • entity
        • 聚合根
        • 实体
        • 值对象
        • 工厂模式（Factory）
      • event 事件实体以及与事件活动相关的业务逻辑代码
      • repository 所在聚合的查询或持久化领域对象的代码，通常包括仓储接口和仓储实现方法 Data Model只存在于数据层，而Domain Model在领域层，而链接了这两层的关键对象，就是Repository [7]
      • service 领域服务是多个实体组合出来的一段业务逻辑

  • Infrastructure

    • config
    • Util（开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库、通用算法等基础代码，）

项目代码[20] #

框架 #

  • Axon Framework
  • COLA [22]

参考 #