都在聊 DDD，到底哪里超越了MVC?

关注Java核心技术，推送更多 Java 干货！

来源：juejin.cn/post/6917125801460629518

前言

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

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

贫血模型

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

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

应用层（即Service层）

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

领域层（或者叫模型层）

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

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

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

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

关注Java核心技术，推送更多 Java 干货！

优点

简单：

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

缺点

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

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

充血模型

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

比如一个人：

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

为什么要有一个“人Manager”这样的东西存在去帮人“打游戏”呢？举个简单的J2EE案例，设计一个与用户（User）相关功能。最新 Java 面试题出炉！分享给你。

传统的设计一般是：

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

充血的设计则可能会是：

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

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

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

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

最近好文分享

---

更多请关注 • Java核心技术

一个分享Java核心技术干货的公众号

点击阅读原文获取面试题～