DDD

领域驱动设计

四层模型的软件设计

将传统软件设计是三层模型MVC，DDD是四层模型：用户界面层、应用层、领域层、基础设施层。它通过分层解耦来解决复杂业务系统的设计难题。与传统三层模型相比，它有更明确的职责划分和领域聚焦。

  • 用户界面层：Controller、ViewModel、

    • 接收输入数据并转换为DTO
    • 不包含业务逻辑
    • 负责权限验证等基础校验
    • 返回HTTP状态码和错误信息

  • 应用层：

    • 职责：协调领域对象完成业务、事务管理、安全控制、事件发布
    • 薄层（理想厚度<100行/Service）
    • 不包含核心业务规则
    • 负责跨聚合协调

  • 领域层：

    • 职责：封装核心业务逻辑、维护业务规则和状态、定义业务概念和流程
    • 系统核心（最复杂且最重要的层）
    • 与技术实现完全解耦
    • 充血模型（业务逻辑在领域对象内）

  • 基础设施层

    • 职责：提供技术实现支持、实现持久化机制、集成外部服务
    • 纯技术实现层
    • 依赖领域层接口
    • 可替换性（不同实现可插拔）

何时选择DDD四层模型

适用场景 ✅

  1. 复杂业务系统（保险、金融、电商）
  2. 长生命周期项目（持续演进5年以上）
  3. 多团队协作（需要明确上下文边界）
  4. 高业务规则密度（数百条业务规则）

不适用场景 ❌

  1. 简单CRUD应用
  2. 短期原型项目
  3. 技术工具类开发
  4. 报表生成等数据导向系统

统一语言

战略设计

定义：领域、子域（核心域、支撑域、通用域）、限界上下文

战术设计

定义：实体、值对象、聚合、聚合根、领域服务、领域事件、领域模型

领域建模

领域驱动设计的核心在于领域建模，架构师的水平高低在很大程度上也体现在领域建模水平上。

领域建模的主要目的是捕捉业务知识，形成统一语言，沉淀领域模型。好的领域建模就意味着对业务要有深刻的理解，能够洞察问题本质。领域建模的产出物一般有以下内容：

  • 领域模型：包含领域对象、属性、关系、行为、边界范围等各个方面，用于描述业务的本质，这也是最重要的产出物。
  • 用例图：用于明确系统的功能。
  • 数据模型：描述系统的数据结构和关系，包括实体关系模型、关系数据库模型等。
  • 状态图：用于描述系统各个状态及其转移条件。
  • 活动图：用于描述系统流程中的各个活动及其关系。
  • 序列图：描述系统中各个对象之间的交互过程和消息传递序列。
  • 架构模型：包含系统的物理和逻辑结构，包括组件、模块、接口等。