DDD领域驱动（四）—

前边两篇，我们讲述为什么用DDD？DDD如何做好需求梳理？DDD如何在系统的层面拆分为粗细粒度合适微服务，以及微服务的架构划分。也就是我们经常说的自顶向下的拆分，现在我们将要做的功能具体拆分到具体的服务上了，也有了菱形架构、四边形架构等骨架，那么接下来就需要我们进行领域的建模了，也就是传统软件设计中的详细设计了。先看下，这个阶段的重要点：

好，先说一下，我们传统的软件详细设计都是怎么做的？ER图进行业务抽象建模，根据ER图进行数据设计，功能流程图、时序图，数据流图，类图、状态图等通过抽象分析设计表、流程、数据扭转、状态、抽象接口类方法等方面，进行详细设计，进而有了可以编码的“说明书”。

而DDD呢？其实一些进行分析抽象设计的方法是公用的，我一直觉得每种方式方法论都有其的优势与劣势，我们不要将其边界划分的太割裂，要善于取其精华去其糟粕。例如我认为流程图、时序图、思维导图等是非常好用的工具，在任何地方都可以去善于应用的。好，接下来我们看下DDD中领域建模几个核心点：

一，实体（entity）、值对象(value object)

实体：实体是我们统一语言中，根据现实生活、具体业务进行抽象的，具有唯一标识，可变性，具有生命周期等特性。而且DDD中的实体，经常会设计成充血模型（充血、贫血模型可参考《充血模型VS贫血模型》）。和现实对比一下：人（类）有手、脚、嘴、鼻子……（属性），可以拿东西、踢足球、吃饭、闻气味（方法能力），不像传统的类，只有get、set方法，而具体的功能方法都在业务类中。

值对象：通过对象属性值来识别对象，它将多个相关属性组合为一个概念整体。其实就是在业务中用来传输一些属性值的合体。没有生命周期，不可变、不具有唯一标识等。

举个例子：在用户下单购买物品时，订单就是一个实体，根据统一语言抽象为订单，具有唯一订单号，进行下单过程订单的某些属性会不停的改变，订单完成以后生命周期也就结束了，其中订单的各种变化，都已在实体中具有其对应的功能方法（充血）；而在统计业务中，单笔订单就可以设计为值对象，主要是为了传输其属性值，值不可变，没有生命等。也就是实体和值对象不是绝对的，而且在不同的场景身份会进行相应的改变。

最后，想聊下，为什么DDD推崇实体实现用充血模型呢？个人感觉是：更符合现实生活，更加容易理解。当然更重要的内聚更高，从而更易扩展，也就更易应对业务需求的变化了……

二，聚合（Aggregate）、聚合根（AggregateRoot）

聚合（Aggregate）,实体和值对象其实个体，就像现实生活一样，我们有个人有团体，而聚合就类似团体，而聚合根可以理解为其领导（或者和外边打交道的角色）。聚合其实就是为了某个业务，抽象的高内聚的边界。

如何设计聚合呢？

1，采用事件风暴；

2，从众多实体中选出适合作为对象管理者的根实体，也就是聚合根；

3，根据业务单一职责和高内聚原则，找出聚合根关联的所有紧密依赖的实体和值对象；

4，在聚合内根据聚合根、实体和值对象的依赖关系，画出对象的引用和依赖模型；

5，多个聚合根据业务语义和上下文一起划分到同一个限界上下文内；

聚合一些设计原则：

1，在一致性边界内建模真正的不变条件（抽象业务）

2，尽量小的聚合（善于管理、更容易应对变化）

3，通过唯一标识引用其他聚合（低耦合）

4，聚合之间使用最终一致性（领域事件-低耦合）

看下经常用的几种对象：

1，数据持久化对象 PO(PersistentObject)，与数据库结构一一映射，是数据持久化过程中的数据载体。

2，领域对象 DO（DomainObject），微服务运行时的实体，是核心业务的载体。

3，数据传输对象 DTO（Data TransferObject），用于前端与应用层或者微服务之间的数据组装和传输，是应用之间数据传输的载体。

4，视图对象 VO（ViewObject），用于封装展示层指定页面或组件的数据。

三，领域服务、领域事件

领域服务：将抽象的业务进行封装实体、值对象、聚合等对外提供的服务Domain Service。

领域事件：领域之间的异步交互业务处理，我们常用的mq处理机制publish和 subscribe。

领域建模，就是在上篇的大的划分架构基础上，对具体的业务进行设计，抽象出实体、值对象，组合出聚合根，对外暴露出服务，设计出事件异步处理功能。从而是微服务达到有架构有肉的饱满的目的。进而完成微服务的实现。

其实在这里想说几点：1，抽象是核心；2，自顶向下的拆分是方法；3，高内聚低耦合是追求；4，易扩展、易复用，易维护是目的。

DDD领域驱动（四）——之领域建模相关推荐

浅谈我对DDD领域驱动设计的理解
从遇到问题开始当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品 ...
DDD 领域驱动设计落地实践：六步拆解 DDD
引言相信通过前面几篇文章的介绍,大家对于 DDD 的相关理论以及实践的套路有了一定的理解,但是理解 DDD 理论和实践手段是一回事,能不能把这些理论知识实际应用到我们实际工作中又是另外一回事,因此本 ...
架构设计之路 - DDD领域驱动模型设计 - 补充中20220315
文章目录前言一.架构的演变历程二.领域驱动初窥 1 传统软件开发中的痛点 2 什么是领域驱动设计战略设计战术设计总结 3 领域模型 4 分层架构模型三层架构四层架构六边形架构三.架 ...
【DDD落地实践系列】DDD 领域驱动设计落地实践：六步拆解 DDD
引言相信通过前面几篇文章的介绍,大家对于 DDD 的相关理论以及实践的套路有了一定的理解,但是理解 DDD 理论和实践手段是一回事,能不能把这些理论知识实际应用到我们实际工作中又是另外一回事,因此本 ...
DDD领域驱动设计落地实践系列：战略设计和战术设计
引言通过前面的文章介绍,相信大家对于什么是DDD有了初步的了解,知道它是一种微服务的架构设计方法论,为我们解决如何建立领域模型,如何实现微服务划分等提供了方向和指导.但是对于如何具体落地使用DDD, ...
DDD领域驱动（二）——之需求梳理
上一篇<DDD领域驱动(一)--之引入>中,我们阐述了中台.微服务.DDD,并从面向对象的基础出发,软件工程的基础出发,简单介绍了DDD,把DDD的知识列了一个框架.让我们对DDD所处于的 ...
DDD 领域驱动设计
从遇到问题开始当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品 ...
DDD 领域驱动设计落地实践系列：战略设计和战术设计
引言通过前面的文章介绍,相信大家对于什么是 DDD 有了初步的了解,知道它是一种微服务的架构设计方法论,为我们解决如何建立领域模型,如何实现微服务划分等问题提供了方向和指导.但是对于如何具体落地使用 ...
C#进阶系列——DDD领域驱动设计初探（五）：AutoMapper使用
前言:前篇搭建了下WCF的代码,就提到了DTO的概念,对于为什么要有这么一个DTO的对象,上章可能对于这点不太详尽,在此不厌其烦再来提提它的作用: 从安全上面考虑,领域Model都带有领域业务,让Cl ...
[转]浅析DDD(领域驱动设计)
最近在做一些微服务相关的设计,内容包括服务的划分,Restful API的设计等.其中比较棘手的就是Service的职责划分:如何抽象具有统一业务范畴的Model,使其模块化,又如何高度提炼并组合多模 ...

DDD领域驱动（四）——之领域建模

DDD领域驱动（四）——之领域建模相关推荐

最新文章

热门文章