虚构的案例，真实的实践

当我在考虑如何以最好的方式向读者展示现代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、留言板(messageboard)、文档管理(document management)、通知(announcement)和提醒(alert)、活动跟踪(activity tracking)和RSS等。所有的这些协作工具都旨在满足企业业务的需求，帮助他们在项目中提高工作效率。在这个经济步伐不断加快的时代里.业务协作对于企业氛围的营造起着重要的作用。任何有助于提高生产率、鼓励知识分享和增进团队协作的实践都是企业成功的促成因素。

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

第二套产品名为ProjectOvation.这是该公司的开发团队主要关注的核心域。ProjectOcation主要用于敏捷项目的管理.使用Scrum作为项目管理方式，并且采用增量式的管理框架。该产品采用传统的Scmm项目管理模型.其中包括产品(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模型和PrajectOvation模型得到了正式地分离,但是这也是偶然的,并不意味着团队就是了解限界上下文的,而这也是为什么该团队在一开始就遇到了问题的原因。不学就得落后啊。

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