虚构的案例，真实的实践

当我在考虑如何以最好的方式向读者展示现代DDD的实践指导时，我希望对每个知识点都做周到的解释。这意味着我不但需要解释“怎么做”，还需要解释“为什么这么做”。通过案例研究，我可以阐述为什么我会给出这样那样的建议，以及DDD是如何解决我们日常遇到的困难的。

有时，我们可以了解一下其他团队所面临的问题和他们在DDD上所犯的错误，而这比单纯地讲解DDD更加容易。通过学习别人的经验教训，我们可以对自己做出评判，避开潜在的错误，向着正确的方向迈进。

我并不打算以我曾经工作过的实际项目作为本书案例（当然这也是我不能公开讨论的），而是采用一个虚构的案例，但是里面却包含了真实的经验和实践。在这个虚构案例中，我将展示实现DDD的最好方式及其原因。

在这个虚构的案例中是一个虚构的公司，公司里有一个虚构的开发团队，他们有真实的业务章程，并且有一个真实的软件系统需要开发部署，而他们所面临的DDD挑战和问题也是真实存在的。我发现这种案例是很有效的，同时我也希望你能从中获益。

在这个团队进行开发的不同阶段，我们将看到他们所面临的种种问题，同时我们还将看到他们是如何解决这些问题并且逐步走向成功的。该团队所开发核心域的复杂性对于讲解DDD是足够的。另外，不同限界上下文之间存在依赖关系，这将有助于我们学习限界上下文的集成。然而，其中的三个示例模型并不能覆盖到DDD战略设计的各个方面。我并不刻意回避那些看似不相关的地方，而是在有必要给出建议的时候就给出建议。

那么现在，请允许我介绍这家虚构的公司，它的团队和软件项目。

SaaSOvation，它的产品和对DDD的使用

这个公司叫做SaaSOvation。正如它的名字所暗示，该公司旨在开发一系列SaaS（Software as a Service，软件即服务）产品，这些产品作为一种服务被订阅用户使用。公司计划先后开发两套产品。

旗舰产品名为CollabOvation，这是一套企业协作（collaboration）软件，并且加入了社交网络的功能。该产品的功能包括论坛（forum）、共享日历（shared calendar）、博客（blog）、即时消息（instant message）、wiki、留言板（message board）、文档管理（document management）、通知（announcement）和提醒（alert）、活动跟踪（activity tracking）和RSS等。所有的这些协作工具都旨在满足企业业务的需求，帮助他们在项目中提高工作效率。在这个经济步伐不断加快的时代里，业务协作对于企业氛围的营造起着重要的作用。任何有助于提高生产率、鼓励知识分享和增进团队协作的实践都是企业成功的促成因素。

CollabOvation希望给客户带来有价值的产品；而对于开发者，他们所面对的挑战也是富有意义的。

第二套产品名为ProjectOvation，这是该公司的开发团队主要关注的核心域。ProjectOcation主要用于敏捷项目的管理，使用Scrum作为项目管理方式，并且采用增量式的管理框架。该产品采用传统的Scrum项目管理模型，其中包括产品（product）、产品负责人（product owner）、团队（team）、待定项（backlog item）、计划发布（planned release）和冲刺（sprint）。对待定项的评估通过对业务价值的分析来确定。

CollabOvation和ProjectOvation并不是两套互不相关的产品。SaasOvation公司非常看重敏捷软件开发过程中的团队协作。因此，CollabOvation可以作为ProjectOvation的增值服务。毫无疑问，在项目计划和团队讨论中使用协作工具将是一个不错的选择。SaasOvation公司预测，60%的ProjectOvation用户将使用CollabOvation所提供的功能，这将在很大程度上增加CollabOvation的销量。一旦建立起了销售渠道，而用户团队也意识到了协作工具的好处，他们很有可能购买整套CollabOvation产品。基于此，SaasOvation公司进一步做出预测，至少35%的ProjectOvation用户会全面使用CollabOvation，这还只是一个很保守的预测。

首先启动的项目是CollabOvation。该团队中有为数不多的几个“老兵”，但大量的是些中级开发人员。在项目组的早期会议中，他们决定采用DDD。其中一个高级开发者在他上家公司中使用过非常有限的DDD。在他谈到自己DDD经验之后，我们可以看出他并没有全面地使用DDD，他使用的其实是DDD-Lite。

DDD-Lite是DDD战术模式的一个子集，它并不强调对通用语言的使用。此外，DDD-Lite通常也忽略了限界上下文和上下文映射图。更多的，DDD-Lite是关于技术实现层面的，虽然这也是有好处的，但是好处并没有与DDD战略模式一同使用时那么大。SaaSOvation决定采用DDD-Lite，然而不久之后他们就遇到问题了，因为他们并不了解子域和限界上下文。

更糟糕的是，SaaSOvation虽然避开了DDD-Lite的陷阱，但这纯属侥幸，因为他们的两套核心产品自然地形成了各自的限界上下文。这也使得CollabOvation模型和ProjectOvation模型得到了正式地分离，但是这也是偶然的，并不意味着团队就是了解限界上下文的，而这也是为什么该团队在一开始就遇到了问题的原因。不学就得落后啊。

通过调查SaaSOvation对DDD的不完整使用，我们可以学到很多。该团队从他们所犯的错误中学到了如何使用DDD的战略设计。同时，我们还可以从CollabOvation团队所做的修改调整中受益匪浅。前人栽树，后人乘凉，之后的ProjectOvation团队也从CollabOvation的回顾会议中学到不少。完整的故事，请参考子域（2）、限界上下文（2）和上下文映射图（3）。