DDD实战笔记(1) 什么是DDD领域驱动

1. 概述

DDD 是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演进的问题。DDD 不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现架构演进。

2.什么是领域？

DDD通过分析业务，最终构建成一个个“领域”，设计出一个个富含业务行为的、饱满的“领域模型”。

在DDD里，“领域”指的就是一块业务范围。比如在一个电商系统中，可能会有“商品领域”、“订单领域”、“物流领域”、“仓储领域”等等。DDD通过战略部分指导我们根据业务划分出业务领域，并区别出哪些是核心领域，哪些是支撑领域和通用领域。这个我们会在本系列后面的文章中详细解释。

“领域模型”指的是业务的载体对象，比如“商品”、“订单”等等。这些对象具有一些有业务含义的方法，比如“商品.加入购物车”方法。我们把主要的业务逻辑内聚在领域对象里，这样一个操作要做的事情就变得非常清晰，并且易于维护。

简单来说，“领域”和“领域模型”能够更直观地表现业务，把业务真正落地到系统架构和代码设计上。

3.什么时候适合DDD设计？

一般来说，DDD适用于“业务复杂”的且“需要维护和扩展”的系统。

首先，我们来看看什么叫业务复杂。试想一下，如果你的系统只需要对几个简单的表进行CRUD，那你不需要使用DDD，甚至都不需要开发一个应用程序，直接使用一个数据库客户端可能就能解决问题。

从经验上来看，如果你的系统有30个以内的业务操作或用户故事，那也是没有太大必要去使用DDD的。而如果超过三四十个，软件就会有一定的复杂性，这个时候就可以考虑使用DDD了。

4.DDD能提供什么？

进入微服务架构时代以后，微服务确实也解决了原来采用集中式架构的单体应用的很多问题，比如扩展性、弹性伸缩能力、小规模团队的敏捷开发等等。

但在看到这些好处的同时，微服务实践过程中也产生了不少的争论和疑惑：微服务的粒度应该多大呀？微服务到底应该如何拆分和设计呢？微服务的边界应该在哪里？

可以说，很久以来都没有一套系统的理论和方法可以指导微服务的拆分，包括微服务架构模式的提出者 Martin Fowler 在提出微服务架构的时候，也没有告诉我们究竟应该如何拆分微服务。

用 DDD 设计方法来建立领域模型，划分领域边界，再根据这些领域边界从业务视角来划分微服务边界。而按照 DDD 方法设计出的微服务的业务和应用边界都非常合理，可以很好地实现微服务内部和外部的“高内聚、低耦合”。
DDD 是一种处理高度复杂领域的设计思想

5.DDD 设计理念

DDD 包括战略设计和战术设计两部分。

战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。

战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。

我们可以用三步来划定领域模型和微服务的边界。

第一步：在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。

第二步：根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。在这个图里，聚合之间的边界是第一层边界，它们在同一个微服务实例中运行，这个边界是逻辑边界，所以用虚线表示。

第三步：根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。在这个图里，限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界，不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离，所以是物理边界，边界之间用实线来表示。

6.DDD 与微服务的关系？

DDD 是一种架构设计方法，微服务是一种架构风格，两者从本质上都是为了追求高响应力，而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发，其核心要义是强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力，也就是我们常说的演进式架构。

DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。

微服务主要关注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。