关注△mikechen的互联网架构△，10年+BAT架构经验倾囊相授

大家好，我是 mikechen | 陈睿 。

DDD 领取驱动是非常热的架构设计，微服务也有大量涉及，下面我就全面来详解 DDD。@mikechen

DDD

DDD，全称是：“Domain-Driven-Design”，翻译过来就是：领域驱动设计(DDD）。

DDD，最早是埃里克·埃文斯（Eric Evans），出版了《领域驱动设计》这本书，标志着领域驱动设计（DDD）的正式诞生。

DDD 强调以业务需求为中心，以领域模型为核心，通过不断迭代开发，确保软件系统能够准确反映业务逻辑、和需求。

DDD原理

在领域驱动设计（DDD）中，领域模型通常被分为四层，以帮助开发人员将业务逻辑、与技术实现，进行有效的分离。

如下图所示：

DDD 的四层架构，提供了一个清晰的分层结构，使得系统的各个部分职责分明。

1.用户界面层

用户界面层，负责与用户交互，显示数据并收集用户输入。

这一层主要处理 UI/UX 逻辑，如：数据展示、用户输入验证.........等。

它是系统的入口，通过各种用户界面，比如：如网页、移动应用、桌面应用、与最终用户进行交互。

2.应用层

应用层定义了系统的主要用例，通过服务接口暴露这些用例，以便用户界面层调用。

该层负责管理事务、协调不同领域对象的交互，以及处理用户请求的工作流。

应用层还负责管理事务、一致性，以及调度各种领域对象，以完成用户的业务需求。

比如：电商系统中的订单管理、库存管理、客户账户管理.....等核心业务逻辑。

3.领域层

领域层是 DDD 的核心部分，负责：实现业务逻辑和规则。

DDD ，包含了领域模型（比如：实体、值对象、聚合、领域服务...等），这些模型直接反映了业务需求。

领域层具有高度内聚性，所有业务逻辑都集中在这一层，避免逻辑分散。

4.基础设施层

基础设施层，负责技术实现的细节，比如：持久化、消息传递、外部系统集成、日志记录等。

比如：MySQL 数据库访问层、Redis 缓存层、Kafka 消息队列集成.......等等。

基础设施层应尽量、与领域层、和应用层解耦，以保持系统的灵活性、和可替换性。

通过这种分层设计，开发团队可以更好地管理系统的复杂性，确保业务逻辑的准确性和系统的可维护性。

DDD实践

DDD 的实施，一般包含如下步骤：

1.领域

首先，通过与领域专家的紧密合作，深入理解业务领域，识别核心子领域、和业务逻辑。

领域是指一个特定的业务领域、或问题空间。

DDD 强调对领域的深入理解，以构建符合业务需求的软件系统。

领域内的所有规则、术语和概念都是业务专家、和开发团队共同理解、和认同的。

比如：电商系统的“领域”，可以是整个在线购物平台，它包括了：商品管理、订单处理、支付系统、客户管理等多个子领域。

这个领域中的所有业务规则、和活动，都围绕着：如何支持用户购买商品、处理订单、进行支付等关键业务功能。

2.领域模型

领域模型是对领域内概念的抽象和简化，是 DDD 中的核心。

领域模型通过实体、值对象、聚合等构建块来描述业务逻辑和规则。

3.限界上下文

限界上下文，是在一个大的领域内划定的一个明确边界，用于划分、和隔离不同子域或模型的区域。

在不同的限界上下文内，相同的术语可能具有不同的含义。

一个限界上下文包含一个清晰定义的领域模型，确保在该上下文中，概念的一致性、和统一性。

如下图所示：

比如：在电商系统中，不同的限界上下文，可能包括“订单管理上下文”、和“库存管理上下文”。

订单管理上下文：

处理用户订单的创建、修改、支付、取消....等功能。

在这个上下文中，“订单”主要涉及客户信息、支付状态。。。等。

库存管理上下文：

负责管理商品的库存数量、仓库位置。。。等。

在这个上下文中，“订单”更多地与库存扣减、出货等操作相关。

4.模型驱动设计

模型驱动设计是DDD的核心理念，它主张以领域模型为基础，来驱动软件系统的设计与开发。

比如：在订单管理上下文中，团队通过与领域专家讨论，创建了一个领域模型。

其中包括“订单（Order）”、“订单项（OrderItem）”...等实体，以及订单的各种状态（如“待支付”、“已支付”、“已发货”等）。

该模型驱动了系统的设计，开发团队根据模型定义数据库结构、API接口和业务逻辑，实现了与订单相关的功能。

5.聚合

聚合是指一组相关对象的集合，通常通过聚合根进行访问、和管理。

聚合根是控制、和管理聚合内部状态的一部分，它负责维护聚合的一致性。

比如：在订单管理上下文中，“订单”可以作为一个聚合，包含：“订单项（OrderItem）”、和“支付信息（PaymentInfo）”。

在这个聚合中，所有操作都通过订单这个聚合根来进行，以确保聚合内部的规则和约束得以维护。

6.实体

实体是具有唯一标识的对象，其生命周期贯穿系统中的多个状态转变。

实体的标识符通常是不可变的，而它的状态可以变化。

在校园教务系统中，“学生（Student）”就是一个实体。

如下图所示：

每个学生都有一个唯一的学号作为标识符，即使学生的姓名、地址等其他属性发生变化，学号仍然保持不变，学号是这个实体的唯一标识。

7.值对象

在“学生信息管理上下文”中，“联系方式（ContactInfo）”可以作为一个值对象。

联系方式（ContactInfo）：包含电话、邮箱...等信息。

DDD领域驱动设计，可以帮助团队更好地组织、和管理复杂的业务逻辑，使系统能够有效应对业务需求的变化。

以上，是 DDD 的详细解析，欢迎评论区留言交流或拓展。

我是 mikechen | 陈睿 ，关注【mikechen的互联网架构】，10年+BAT架构技术倾囊相授。

新的架构专题内容，第一时间更新至：阿里架构师进阶全部合集。

本文已同步我的技术博客 www.mikechen.cc，更新至我原创的《30W+字阿里架构技术合集》中。