一名词概念解释

ddd

领域驱动设计（Domain-driven design），是一种架构设计方法，主要从业务领域视角划分领域边界，构建通用语言，进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。

一般我们说微服务的时候，是离不开ddd的，微服务是一种具体的架构设计落地方案，而ddd是微服务拆分和具体落地的指导方法。

领域

百度百科：具体指一种特定的范围或区域。
维基百科：指某一专业或事物方面范围的涵盖。
google：学术研究、思想意识或社会活动的范围。

可以看到，领域指的是某一个范围，ddd的领域就是这个边界范围内要解决的业务问题，这也是我们在讨论领域设计时，一定要先确定好领域边界的重要性。

子域

领域还可以再细分为多个子域，每个子域对应一个更小的问题域或更小的业务范围。

子域根据自身的重要性和功能属性的不同，可以划分为核心域、通用域、支撑域三大类。

核心域

决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力。

不同的业务场景，核心域的定义也不同，例如一家做交易的公司，核心域是订单系统。但是在一家做支付的公司，核心域就是账单系统。

通用域

没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。

支撑域

还有一种功能子域是必需的，但既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，它就是支撑域。

其实我对通用域和支撑域的区别也并不是很了解，我们只需要识别出核心域就好了，把主力放在核心域的建设上，不断提供公司的核心竞争力。

限界上下文

限界就是领域的边界，而上下文则是语义环境。

我们在讨论ddd领域模型时，首先需要确定的就是限界上下文，只有确定需要讨论的问题和模型是在同一个上下文环境中，后续的讨论才是有意义的，是在同一个频道的。

例如在讨论订单模型设计时，在交易领域内，订单是核心模型，是聚合根。但是在支付领域内，订单只是支付账单的一个值对象。

实体

拥有唯一标识符，且标识符在历经各种状态变更后仍能保持一致。对这些对象而言，重要的不是其属性，而是其延续性和标识，对象的延续性和标识会跨越甚至超出软件的生命周期。我们把这样的对象称为实体。

实体一般对应业务对象，它具有业务属性和业务行为，一个实体可以包含一个或多个值对象。

比如我们的身份证就是一个实体，它有身份证编号，你改了名字、换了住址，但是身份证编号是不会变的。

值对象

值对象没有唯一标识，它是通过属性值来识别的，它是将一个或多个属性聚合为一个整体的概念。主要用来描述实体的状态和特征。

我们在购物的时候，需要填写收货地址，这里的收货地址就是值对象，它将国家、省份、市、区、街道以及详细地址等多个属性整合为一个整体，改了其中任何一个属性值，它都是一个新的值对象。

聚合

实体和值对象都是个体化的对象，它们的行为表现出来的是个体化的能力。能让实体和值对象协同工作的组织就是聚合，它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。

订单就是一个标准的聚合，订单在整个生命周期中，会根据状态的变化，订单数据也会跟着变化。例如订单支付完成，支付金额、支付时间、支付方式等信息会更新到订单的支付值对象上，订单的状态也会跟着变为已支付，订单这个聚合需要保证支付值对象的数据和订单状态的变更是一致的。

聚合根

聚合根是为了避免由于复杂数据模型缺少统一的业务规则控制，而导致聚合、实体之间数据不一致性的问题。

首先它作为实体本身，拥有实体的属性和业务行为，实现自身的业务逻辑。

它还是聚合对外的接口人，以聚合根 ID 关联的方式接受外部任务和请求，在上下文内实现聚合之间的业务协同。也就是说，聚合之间通过聚合根 ID 关联引用，如果需要访问其它聚合的实体，就要先访问聚合根，再导航到聚合内部实体，外部对象不能直接访问聚合内实体。

还是回到订单这个例子，订单在交易系统内就是聚合根，它聚合了订单基本信息、买家信息、卖家信息、商品信息、权益信息、支付信息、履约信息等等实体和值对象，并且订单这个聚合根确保了在订单生命周期过程中所有数据变更的数据一致性，且对外提供订单自身的业务方法。

不同概念之间的关系如下图

以上图片来自网络，侵删

二战略设计

通过 DDD 战略设计可以建立领域模型，划定领域边界，解决微服务设计过程中，边界难以划定的难题，还可以根据ddd中定义的聚合以及聚合根，拆分具体的微服务。

战略设计我理解的就是根据界限上下文确定微服务边界、根据聚合和聚合根确定具体的微服务。

电商场景：供应链、仓储、商品、库存、会员、权益（营销、scrm）、交易（订单）、支付、履约、物流等。

三战术设计

战术设计是ddd落地的具体指导方法，也可以理解为怎么通过ddd的方式实现一个具体的微服务系统设计开发。

先熟悉下ddd系统开发过程中需要用到的概念：

仓储服务（repository）

持久化领域对象的服务，一般是数据库或缓存服务等实现。

领域工厂（factory）

复杂领域实体的构建提供的工厂方法。

领域实体（entity）

上面有说过。

值对象（value object）

上面有说过。

领域服务（domain service）

涉及到多个聚合或聚合根或实体等在一起实现某个领域功能时，可以通过领域服务实现。

领域事件（event）

多个聚合或聚合根之间的消息通讯（事件通知），在同一个系统内可以通过event bus实现，方便后期做微服务的系统拆分，在不同系统内可以通过消息中间件mq实现。

基础设施（infrastructure）

我们常用的数据存储mysql、redis等都可以算作基础设施。

依赖服务（dependency）

依赖的其他微服务提供的接口服务。

业务服务（application service）

业务服务对外暴露的每一个方法都是一个具体的业务用例。可以对应到我们技术方案设计中的用例图，用例图中的每一个具体的用例实现，就是业务服务内的public方法。

下面是个人理解的ddd落地的一个系统分层及依赖关系

rpc api、rest api：系统对外提供的接口服务；
facade：对外部接口请求参数的合法性校验，并定义业务服务（app 的接口）；
app：通过依赖倒置的设计依赖facade层，并实现facade定义的业务服务，app通过依赖dependency和domain，将领域服务和依赖的三方服务通过组合、编排等方式实现自身的业务用例；
job：系统的定时任务、mq消息监听等；
dependency：依赖的其他微服务提供的接口；
domain：核心领域模块，领域实体、值对象、领域服务、领域仓储接口的定义等。该模块很少根据业务的变更而变化，可以脱离该系统自运行的核心领域功能。
infrastructure：通过依赖倒置的设计依赖domain模块，并实现repository接口，实现领域对象的持久化保存等。

以上就是我实践的ddd落地的项目。

最后建议我们在技术方案设计时，加上一个领域模型设计，这样大家在讨论具体设计细节时，讨论的是领域模型。具体的数据存储是数据模型，我们更应该关注的是自身的领域模型，数据模型可以理解为一个容器，不需要和领域模型完全一致，最好有一定的扩展性，方便领域模型调整时，尽量少调整数据模型。

领域模型vs数据模型，应该怎么用？

写在最后：我理解的ddd战术设计，就是一个代码规范，也可以理解为一种系统分层，大家都按照ddd定义的分层模型去设计开发的话，系统也就更易于维护了。

ddd入门指南及实战落地

ddd入门指南及实战落地

关于作者 📝

目录

评论