学习领域驱动设计

附录 A. 应用DD：案例研究

在本附录中，我将分享我的领域驱动设计之路是如何开始的： 一家初创公司的故事，在本示例中，我们将其称为 "Marketnovus"。在 Marketnovus，我们从公司成立之日起就开始采用领域驱动设计方法。多年来，我们不仅犯下了所有可能的 DDD 错误，而且还有机会从这些错误中吸取教训并加以修正。我将用这个故事和我们犯过的错误来说明 DDD 模式和实践在软件项目成功中所起的作用。

本案例研究包括两个部分。在第一部分中，我将带你了解 Marketnovus 的五个有界情境的故事、做出了哪些设计决策以及结果如何。在第二部分中，我将讨论这些故事如何反映你在本书中学到的知识。

在开始之前，我需要强调的是，Marketnovus 已经不存在了。因此，本附录绝无宣传之意。此外，由于这是一家已不存在的公司，我可以坦诚地讲述我们的经历。

五种有限制的情境

在深入探讨有界上下文及其设计方法之前，作为循规蹈矩的 DDD 实践者，我们必须先定义 Marketnovus 的业务领域。

业务领域

想象一下，您正在生产一种产品或提供一种服务。Marketnovus 允许 您外包所有与营销相关的琐事。Marketnovus 的专家会为您的产品制定营销战略。他们的撰稿人和平面设计师会制作大量的创意材料，如横幅广告和登陆页面，用于开展推广产品的广告活动。Marketnovus 的销售代理将负责处理这些活动所产生的所有销售线索，他们将拨打电话销售您的产品。此流程如图 A-1 所示。

图 A-1. 营销流程

最重要的是，这一营销流程提供了许多优化机会，而这正是分析部门的职责所在。他们对所有数据进行分析，以确保 Marketnovus 及其客户能够获得最大的收益，无论是确定最成功的营销活动、表彰最有效的创意，还是确保销售代理能够获得最有潜力的销售线索。

由于我们是一家自筹资金的公司，我们必须尽快开始运作。因此，公司刚成立，我们软件系统的第一个版本就必须实现价值链的前三分之一：

• 管理合同和与外部出版商集成的系统

• 供我们的设计师管理创意材料的目录

• 运行广告活动的活动管理解决方案

我不知所措，必须找到一种方法，让我的头脑对商业领域的所有复杂问题有所了解。幸运的是，就在我们开始工作前不久，我读到了一本书，书中承诺会做到这一点。当然，我说的是埃里克-埃文斯（Eric Evans）的开创性著作《领域驱动设计》（Domain-Driven Design）：解决软件核心的复杂性问题》。

如果你读过这本书的序言，你就会知道埃文斯的书提供了我寻找已久的答案：如何设计和实现业务逻辑。尽管如此，对我来说，这本书并不是一读就能理解的。尽管如此，我感觉仅仅通过阅读战术设计章节，我就已经很好地掌握了 DDD。

猜猜这个系统最初是如何设计的？这绝对会让滴滴社区的某位杰出人士¹感到非常自豪。

有界背景 1：市场营销

我们第一个解决方案的架构风格可以简洁地概括为 "无处不在的聚合体"。机构、活动、投放、漏斗、出版商：需求中的每一个名词都是聚合体。

所有这些所谓的集合体都居住在一个巨大的、孤独的、有边界的环境中。是的，一个巨大而可怕的整体，就是如今每个人都警告你要小心的那种。

当然，这些都不是聚合体。它们不提供任何事务边界，几乎没有任何行为。所有的业务逻辑都是在一个巨大的服务层中实现的。 ...