DDD领域驱动设计 — 贫血模型与充血模型

最新推荐文章于 2024-02-25 22:32:32 发布

架构文摘

最新推荐文章于 2024-02-25 22:32:32 发布

阅读量150

点赞数

文章标签：编程语言 java python 大数据人工智能

原文链接：https://mp.weixin.qq.com/s?__biz=MzA3ODIxNjYxNQ==&mid=2247502267&idx=1&sn=bf7081934d554be62903b78b96e28e06&chksm=9f44a573a8332c65a52e94ad4c78b74a675d1db76e7194394804387b8acdc56358020d824ab0&scene=126&&sessionid=0

版权

文章转载来源：https://juejin.cn/post/6917125801460629518

| 前言

要想深入掌握和了解 DDD 领域驱动设计的核心，那无论如何也绕不开两大较为抽象的概念——“贫血模型”、“充血模型”：

贫血模型即事务脚本模式。
充血模型即领域模型模式。

| 贫血模型

贫血模型最早广泛应用源于EJB2，最强盛时期则是由Spring创造，将：

“行为”（逻辑、过程）；
“状态”（数据，对应到语言就是对象成员变量）。

分离到不同的对象中：

只有状态的对象就是所谓的“贫血对象”（常称为VO——Value Object）；
只有行为的对象就是，我们常见的N层结构中的Logic/Service/Manager层（对应到EJB2中的Stateless Session Bean）。

——曾经Spring的作者Rod Johnson也承认，Spring不过是在沿袭EJB2时代的“事务脚本”，也就是面向过程编程。

贫血领域模型是一个存在已久的反模式，目前仍有许多拥趸者。

Martin Fowler 曾经和 Eric Evans 聊天谈到它时，都觉得这个模型似乎越来越流行了。作为领域模型的推广者，他们觉得这不是一件好事。

贫血领域模型的基本特征是：它第一眼看起来还真像这么回事儿。项目中有许多对象，它们的命名都是根据领域来的。对象之间有着丰富的连接方式，和真正的领域模型非常相似。但当你检视这些对象的行为时，会发现它们基本上没有任何行为，仅仅是一堆getter/setter。

其实，这些对象在设计之初就被定义为只能包含数据，不能加入领域逻辑；逻辑要全部写入一组叫Service的对象中；而Service则构建在领域模型之上，需要使用这些模型来传递数据。

这种反模式的恐怖之处在于：它完全和面向对象设计背道而驰。面向对象设计主张将数据和行为绑定在一起，而贫血领域模型则更像是一种面向过程设计，Martin Fowler和Eric在Smalltalk时就极力反对这种做法。更糟糕的是，很多人认为这些贫血领域对象是真正的对象，从而彻底误解了面向对象设计的涵义。

如今，面向对象的概念已经传播得很广泛了，而要反对这种贫血领域模型的做法，还需要更多论据。贫血领域模型的根本问题是，它引入了领域模型设计的所有成本，却没有带来任何好处。最主要的成本是将对象映射到数据库中，从而产生了一个O/R（对象关系）映射层。

只有当你充分使用了面向对象设计来组织复杂的业务逻辑后，这一成本才能够被抵消。如果将所有行为都写入到Service对象，那最终你会得到一组事务处理脚本，从而错过了领域模型带来的好处。正如martin在企业应用架构模式一书中说到的，领域模型并不一定是最好的工具。

将行为放入领域模型，这点和分层设计（领域层、持久化层、展现层等）并不冲突。因为领域模型中放入的是和领域相关的逻辑——验证、计算、业务规则等。如果你要讨论能否将数据源或展现逻辑放入到领域模型中，这就不在本文论述范围之内了。

一些面向对象专家的观点有时会让人产生疑惑，他们认为的确应该有一个面向过程的服务层。但是，这并不意味着领域模型就不应该包含行为。事实上，service层需要和一组富含行为的领域模型结合使用。

Eric Evans的Domain Driven Design一书中提到：

应用层（即Service层）

描述应用程序所要做的工作，并调度丰富的领域模型来完成它。这个层次的任务是描述业务逻辑，或和其它项目的应用层做交互。这层很薄，不包含任何业务规则或知识，仅用于调度和派发任务给下一层的领域模型。这层没有业务状态，但可以为用户或程序提供任务状态。

领域层（或者叫模型层）

表示业务逻辑、业务场景和规则。该层次会控制和使用业务状态，即使这些状态最终会交由持久化层来存储。总之，该层是软件核心。

服务层很薄——所有重要的业务逻辑都写在领域层。他在服务模式中复述了这一观点：如今人们常犯的错误是不愿花时间将业务逻辑放到合适的领域模型中，从而逐渐形成面向过程的程序设计。

我不清楚为什么这种反模式会那么常见。我怀疑是因为大多数人并没有使用过一个设计良好的领域模型，特别是那些以数据为中心的开发人员。此外，有些技术也会推动这种反模式，比如J2EE的Entity Bean，这会让我更倾向于使用POJO领域模型。

总之，如果你将大部分行为都放置在服务层，那么你就会失去领域模型带来的好处。如果你将所有行为都放在服务层，那你就无可救药了。

优点

简单：

对于只有少量业务逻辑的应用来说，使用起来非常自然；
开发迅速，易于理解；
注意：也不能完全排斥这种方式。

缺点

无法良好的应对复杂逻辑：

比如收入确认规则发生变化，例如在4月1号之前签订的合同要使用某规则……
和欧洲签订的合同使用另外一个规则……

| 充血模型

面向对象设计的本质是：“一个对象是拥有状态和行为的”。

比如一个人：

他眼睛什么样鼻子什么样这就是状态；
人可以去打游戏或是写程序，这就是行为。

为什么要有一个“人Manager”这样的东西存在去帮人“打游戏”呢？举个简单的J2EE案例，设计一个与用户（User）相关功能。

传统的设计一般是：

类：User+UserManager；
保存用户调用：userManager.save(User user)。

充血的设计则可能会是：

类：User；
保存用户调用：user.save()；
User有一个行为是：保存它自己。

其实它们没有什么特别适用的方向，个人更倾向于总是使用充血模型，因为OOP总是比面向过程编程要有更丰富的语义、更合理的组织、更强的可维护性—当然也更难掌握。

因此实际工程场景中，是否使用，如何使用还依赖于设计者以及团队充血模型设计的理解和把握，因为现在绝大多数J2EE开发者都受贫血模型影响非常深。另外，实际工程场景中使用充血模型，还会碰到很多很多细节问题，其中最大的难关就是“如何设计充血模型”或者说“如何从复杂的业务中分离出恰到好处且包含语义的逻辑放到VO的行为中”。

如果一个对象包含其他对象，那就将职责继续委托下去，由具体的 POJO 执行业务逻辑，将策略模式更加细粒度，而不是写 ifelse。

参考