DDD

Domain Driven Design(DDD)领域驱动设计, 基于业务逻辑的领域建模和软件开发的设计方法。

方法的演进

• 编程范式：
  过程式（60年代末“软件危机”）-> OOP面向对象（封装、继承、多态）、 FP函数式编程（不持有状态，无副作用）
• 软件架构：
  单机 -> 分布式， 大单体 -> 多微服务
• 软件开发模式：
  瀑布式(需求分析、设计、编码、集成、测试、维护) -> 迭代(每一次迭代都包括了需求分析、设计、实现与测试, 实现产品的一部分，降低风险) -> 螺旋（风险驱动，快速原型+风险评估+实现不断螺旋上升，由小变大） -> 敏捷（强调人的协作、沟通重要性，比迭代模型更短的迭代，随时应对变化）

  https://www.cnblogs.com/tianguook/p/4004726.html

• 设计模式：
  TDD：测试驱动开发（Test-Driven Development）
  BDD：行为驱动开发（Behavior Driven Development）
  ATDD：验收测试驱动开发（Acceptance Test Driven Development）
  DDD: 数据驱动设计（Data Driven Design）
  DDD：领域驱动设计（Domain Driven Design）
  PDD…

架构的腐化

1. 传统的（经典）MVC软件架构(技术视角下的模块划分)

- 数据驱动的设计，重点RDBMS（3rdF范式设计等）、E/R模型和DAO设计。

2. 初期快速实现、快速交付，未充分考虑架构扩展性、性能和可维护性，导致软件开发积重难返。

• 对象的贫血/充血模型
  • 贫血：对象倾向于只持有数据（或包含一堆getter、setter）, 而在复杂的业务行为中对不同的对象内部状态进行访问、设置。这样的“哑对象”只能体现“是什么”，而难以体现系统在“做什么”。在代码开发中，难以从一块代码中了解其对应的具体业务逻辑（业务代码缺乏业务涵义，只是技术上的描述，即贫血模型导致的“失忆症”），代码难以复用，最终业务代码容易变成一片泥潭的混乱状态。
    • 有些行为需要重复实现，违反了不自重复（Don’tRepeatYourself）原则
  • 充血：对象倾向于不仅持有数据，还尽量多地将业务行为封装到自己的方法中。随着业务场景的丰富，这种领域对象会持有更多的数据字段和业务方法，而这些数据和行为的边界往往模糊不清、抽象程度难以一致。特别是在跨多个领域对象的复杂行为，往往需要一个对象要求别的对象向其暴漏其内部状态，造成状态耦合。这样的对象就逐渐变成了“上帝类”。
    • 违反“高内聚、低耦合”原则

DDD

分析即设计，设计即分析。设计即实现，实现即设计。
分析即设计，设计即实现。

• 领域：问题域，一个问题域下面的关键问题，核心问题和问题的边界是确定的。一个系统要解决的总问题即是一个领域，领域可细分为多个子领域。
• 驱动设计：领域知识驱动领域建模的设计，领域模型驱动软件架构及软件的设计、实现。