DDD-领域驱动设计

目录

一、前言

二、DDD是什么？

三、DDD的职责：

复杂系统的应对：

微服务架构：

DDD架构：

四、DDD相关概念：

领域

限界上下文(Bounded Context)

统一语言

五、DDD的实现：

战略建模

内容：

划分限界上下文

限界上下文之间的映射关系(Context Mapping)

战术建模：

内容：

模块(Module)：

实体(Entity)：

值对象(Value Objects)

聚合(Aggregate)

领域服务(Domain Services)

领域事件(Domain Events)

代码分层架构：

DDD落地应对的挑战：

---

一、前言

宏观上：

• 互联网业务发展初期“小步快跑，迭代试错”的情形下要求系统需要快速迭代，但是随着互联网公司逐渐深入实体经济，业务日益复杂，我们在开发中也越来越多地遇到传统行业软件开发中所面临的问题。
• 传统的研发模式中，系统分析和设计是分开的，导致需求和成品非常容易出现偏差，两者相对独立，还会导致沟通困难。
• DDD打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。

微观上：

• Action/Service/DAO这种分层架构下，开发模式通常是面向过程、面向数据的。这种开发模式下，对象只是数据的载体，没有行为。整个开发的过程都是以数据为中心，以数据库ER设计为驱动，面向数据进行开发，即数据驱动设计。
• 业务逻辑都是写在Service中，简单的业务系统采用这种贫血模型和过程化设计是没有问题的，但当业务逻辑复杂了，业务逻辑、状态会散落到在大量方法中，原本的代码意图会渐渐不明确，我们将这种情况称为由贫血症引起的失忆症。
• 随着业务的不断发展，业务逻辑变得越来越复杂，系统的实现逻辑也变得越来约复杂，最后的结果就是没有人能够描述清楚每个细节，当对现有功能进行迭代时，光回顾该功能涉及的流程(涉及的改动点)就需要很长的时间，而且还容易出现梳理遗漏的情况。
• 这种情形下，rd往往通过[新写一套逻辑+开关控制]的方式来完成这次的迭代，该功能之后再经历几次迭代后，同一功能在系统中可能存在多个版本的代码，这样就形成恶性循环，每次迭代都需要花费大量的时间去回顾之前多个版本的代码。
• 最终，当迭代的成本超过了重构的成本，rd就开始对该功能进行重构，重构是克服演进式设计中大杂烩问题的主力，通过在单独的类及方法级别上做一系列小步重构来完成，我们可以很容易重构出一个独立的类来放某些通用的逻辑，但是，重构时会发现你很难给它一个业务上的含义，只能给予一个技术维度描绘的含义。这会带来什么问题呢？新同学并不总是知道对通用逻辑的改动或获取来自该类。显然，制定项目规范并不是好的idea。我们又闻到了代码即将腐败的味道。
• 更好的做法是采用领域模型的开发方式，将数据和行为封装在一起，并与现实世界中的业务对象相映射。各类具备明确的职责划分，将领域逻辑分散到领域对象中。

其它分享：

• 数据驱动设计 VS 领域驱动设计：领域驱动设计峰会-领域驱动设计大揭秘

二、DDD是什么？

• DDD（Domain-Driven Design）：领域驱动设计是一套应对复杂软件系统分析和设计的建模方法论。

三、DDD的职责：

复杂系统的应对：

• 系统的复杂度越来越来高是必然趋势，原因可能来自自身业务的演进，也有可能是技术的创新，然而一个人和团队对复杂性的认知是有极限的，就像一个服务器的性能极限一样，解决的办法只有分而治之，将大问题拆解为小问题，最终突破这种极限，架构设计的4个层面：
  • 业务架构——根据业务需求设计业务模块及其关系 ，关注系统的功能。
  • 系统架构——设计系统和子系统的模块，关注系统的整体性能。
  • 技术架构——决定采用的技术及框架，关注系统的实现方案（框架/缓存/..）
  • 工程架构——代码的分层设计

微服务架构：

• 应对系统架构、技术架构上的挑战(主要是可用性/性能)，通过注册中心、负载均衡、限流、熔断等方案来应对。

DDD架构：

• 应对业务架构、工程架构上的挑战：通过战略建模和战术建模的方式将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。

四、DDD相关概念：

领域

概念：

• 业务范围以及在其中所进行的活动称为领域。

分类：

• 领域可以划分为子域，在领域划分过程中，会不断划分子域，子域按重要程度会被划分成三类：
  • 核心域：核心竞争力，业务成功的主要促成因素。
  • 通用域：不是核心，被整个业务系统使用。
  • 支撑域：不是核心，可以通过购买满足需求。

注意：

• 在建设一个领域模型时，我们通常只关注核心业务(核心域)，而不是试图创建一个全功能的领域模型，因为那样是十分困难的并且还容易导致建模失败。

限界上下文(Bounded Context)

概念：

• 业务流程的实现方案/业务问题的解决方案（eg：软件系统等）称为限界上下文。

作用：

• 限界上下文明确了领域模型的边界。

统一语言

• 定义上下文的含义

• 价值是可以解决不同角色(RD、PM、QA)间的交流障碍

五、DDD的实现：

战略建模

内容：

• 于高层次、宏观上去划分和集成限界上下文。

划分限界上下文

• 每个限界上下文专注于解决某个特定的子域的问题，每个子域都对应一个明确的问题，提供独立的价值，每个子域都相对独立，故各个限界上下文之间也是相对独立的。

限界上下文之间的映射关系(Context Mapping)

• 合作关系（Partnership）：两个上下文紧密合作的关系，一荣俱荣，一损俱损。
• 共享内核（Shared Kernel）：两个上下文依赖部分共享的模型。
• 客户方-供应方开发（Customer-Supplier Development）：上下文之间有组织的上下游依赖。
• 遵奉者（Conformist）：下游上下文只能盲目依赖上游上下文。
• 防腐层（Anticorruption Layer）：一个上下文通过一些适配和转换与另一个上下文交互。
• 开放主机服务（Open Host Service）：定义一种协议来让其他上下文来对本上下文进行访问。
• 发布语言（Published Language）：通常与OHS一起使用，用于定义开放主机的协议。
• 大泥球（Big Ball of Mud）：混杂在一起的上下文关系，边界不清晰。
• 另谋他路（SeparateWay）：两个完全没有任何联系的上下文。

战术建模：

这篇文章不错：DDD 战术设计

内容：

通过模块、聚合、实体、值对象、领域服务、领域事件等对象来细化限界上下文。

模块(Module)：

• 是一种控制限界上下文的手段，在工程中我们一般使用一个模块来表示一个领域的限界上下文。
• 一般的工程中包的组织方式为{com.公司名.组织架构.业务.上下文.*}，这样的组织结构能够明确的将一个上下文限定在包的内部。

实体(Entity)：

• 当一个对象由其标识(而不是属性)区分时，这种对象称为实体。

值对象(Value Objects)

• 当一个对象用于对事务进行描述而没有唯一标识时，它被称作值对象。
• 在实践中，需要保证值对象创建后就不能被修改，即不允许外部再修改其属性

聚合(Aggregate)

• 聚合是一组相关对象(实体、值对象)的集合，作为一个整体被外界访问，聚合是为了保证领域内对象之间的一致性问题。
• 如何创建好的聚合？
  • 聚合边界内必须明确有哪些信息，如果没有这些信息就不能称为一个有效的聚合。
  • 设计小聚合：
    • 大部分的聚合都可以只包含根实体(Aggregate Root)，而无需包含其他实体。
    • 即使一定要包含，可以考虑将其创建为值对象。
  • 通过唯一标识来引用其他聚合或实体：
    • 当存在对象之间的关联时，建议引用其唯一标识而非引用其整体对象。
    • 如果是外部上下文中的实体，引用其唯一标识或将需要的属性构造值对象。
    • 如果聚合创建复杂，推荐使用工厂方法来屏蔽内部复杂的创建逻辑。
  • 边界内的内容具有一致性：
    • 在一个事务中只修改一个聚合实例。
    • 如果你发现边界内很难接受强一致，不管是出于性能或产品需求的考虑，应该考虑剥离出独立的聚合，采用最终一致的方式。
• 常见场景：一个主记录对应多条明细记录的场景。
• 设计方案：
  • 若可以有效控制明细数量，且明细数量较小时，主记录和明细记录可以设计为一个聚合。
  • 若明细数量可能很大时，考虑到性能的问题，我们应该将主记录和明细记录设计为两个聚合，当明细记录更新后发布领域事件，主记录根据明细更新事件做出相应的修改，这样就可以保证主记录和明细记录之间互不依赖。

领域服务(Domain Services)

• 业务逻辑优先在聚合根边界内完成；聚合根中不合适放置的业务逻辑才考虑放到 DomainService 中。

领域事件(Domain Events)

• 领域事件是对领域内发生的活动进行的建模。

代码分层架构：

ddd四层架构

DDD落地应对的挑战：

落地DDD需要应对的挑战

参考：

DDD 模式从天书到实践 - 知乎

领域驱动设计在互联网业务开发中的实践 - 美团技术团队

DDD战术设计，到底如何编码？