实现领域驱动设计
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人

虚构的案例,真实的实践

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

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

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

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

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

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

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

img

这个公司叫做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)。

img