Brook 从一次技术大会回来后，开始尝试一种新的编程范式 —— 从大会上学到的本年度最潮流的编程方法。

"不允许这类蠢问题再次出现，新来实习生总是在处理用户退菜操作的时候忘记更新总价。" Brook 一大早来到公司，一边泡了一杯咖啡一边嘀咕到。

Brook 供职在一家主营外卖的互联网公司，他们的工作就是保证用户能方便的在手机上点需要的食物，并快速的配送到用户手上。 由于人员的变动，他们最近的代码变得有点混乱。

"早该这样做了，应该使用 DDD 的思想，将订单和相关的数据一起更新，就能保证业务规则不被破坏了" Brook 给邻座新来的同事一边打招呼一边说道。

"你好，我是新来的 Java 工程师，可以叫我 Neo。"

"你刚刚是在说 DDD 吗？我没有使用过，倒是经常在同事口中听到这个话题。请问我们是计划重构成这种架构模式吗？" Neo 小心翼翼的打量着 Brook，这个在公司待了超过 8 年的家伙，几乎在公司创建的时候就在这里了。

"是的，我们可以把订单的逻辑都放到 Order 对象上，然后统一存储，而不是在各个地方直接更新数据库。" Brook 顿时来了兴致，难得有人对这个话题感兴趣，虽然有可能是礼貌性的。

"给 Order 赋予行为，而不是把行为散落其他地方，这就是面向对象的高内聚设计。"

"发明 DDD 的人把一组业务一致的对象叫做聚合，这真是一个贴切的名字，如果你有兴趣我可以继续给你讲讲 DDD 中其他睿智的思想。"

Brook 想要一口气把他的想法说完，迫不及待的把这个想法告诉眼前这个新来的人，仿佛找到了解决手上这些遗留代码的钥匙一般。

"这倒是不着急，我读过 Eric DDD 的那本书，但是对其中的某些模式，还有一些疑问。"

"比如，在 Order 这对象中，他应该负责持久化的工作吗？" Neo 问到。

Brook 回想了一下在大会上学到的经验，回答道：

"关于如何持久化领域模型，可以有几种方式。"

"一种是通过应用层，从数据库获取然后把逻辑交给领域模型，完成状态的变化后，再由 Repository 持久化回去，我们把它叫做充血模型。"

"还有一种模式是领域模型提供一个 save 方法，在内部调用 Repository 进行持久化，我们把它叫做胀血模型。"

"而以前那种把业务逻辑放到模型外，散落到各个地方，叫做贫血模型。甚至这种方式都都不配叫做面向对象。"

"DDD 就是把面向对象做到最好的形态。" 说到这里，Brook 甚至有点嫌弃自己以前的设计。

"面向对象就像一个比喻，工程师将现实中的行为映射到代码中。"

"果然编程就像一门艺术，以后多向你请教。" Neo 不忍打断 Brook，直到他一口气讲完。

"不过等等，你说过编程像是在做比喻，把现实中的流程在计算机世界重现？"

"所以我们应该给订单、商品等对象赋予业务逻辑，而不是各种 service？"

"是的"

"哈哈，你这个骗子"

"现实中根本没有可以自己结账的订单。"

"为什么？"

"因为转行成为一名软件工程师之前，我在餐厅做收银员。"