DDD案例说明

1、案例说明

整个专栏的案例来源于一个虚构的公司，公司里有一个虚构的团队，他们真实的业务章程，并且有一个真实的软件系统需要部署开发部署，而他们所面临的DDD挑战和问题也是真实存在的。

这个公司叫做SaaSOvation。正如名字所示，该公司旨在开发一系列SaaS产品，该产品作为一种服务被用户使用。公司计划先后开发两套产品。

1、旗舰产品名为CollabOvation，这是一套企业协作（Collaboration）软件，并且加入社交网络的功能。该产品的功能包括论坛、共享日历、博客、即时消息、wiki、留言板、文档管理、通知和提醒、活动跟踪和RSS等。所以协作工具都旨在满足企业服务的需求，帮助他们在项目中提高效率。

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

collabOvation和project并不是两套互不相关的产品。SaaSOvation公司非常注意敏捷软件开发过程中的团队协作。因此，CollabOvation可以作为ProjectOvation的增值服务。毫无疑问，在项目计划和团队讨论中使用协作工具将是一个不错的选择。这将在很大程度上增加CollabOvation的销量。

首先启动的项目是collabOvation。该团队中有为数不多的几个老兵，但大量的是这些中级开发人员。在项目组的早期会议中，他们决定采用DDD。其中一个高级开发者在上家公司使用过非常有限的DDD。他并没有全面地使用DDD，他使用的其实就是DDD-lite。

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

更糟糕的是，SaaSOvation虽然避开了DDD-Lite的陷阱，但这属于侥幸。因为他们的两套核心产品自然地行程各自的限界上下文。这也使得CollabOvation模型和ProjectOvation模型得到正式的分离，但是这是偶然的，并不意味着团队就是了解限界上下文的。

2、示例上下文

我们的SaaSOvation团队所选择的3个限界上下文最终将与各自所对应的子域形成一对一的关系。在汲取经验教训之后，最终的结果如下：

接下来将介绍这3个模型如何形成一个实际的、现代的企业级解决方案，在实际应用中，一个项目总会有多个限界上下文，他们之间的集成对于当今的企业来说是一个非常重要的环节。除了限界上下文和子域，我们还需要掌握上下文映射图来解决集成问题。

让我们来看看示例DDD项目中的这3个限界上下文，分别是协作上下文、身份与访问上下文和敏捷项目上下文。

3、协作上下文

在当今这个经济疾步向前的时代中，业务协作工具对于创建一个协作式的工作环境来说是非常重要的。SaaSOvation也希望从这个市场中分到一杯羹。

负责设计和实现协作上下文的核心团队需要在第一次软件发布中包括以下功能：论坛、共享日历、博客、即时消息、wiki、留言板、文档管理、通知与提醒、活动跟踪和RSS订阅。虽然核心团队要开发的功能很多，但是每一个协作工具都可以单独使用。但这些工具都属于同一个限界上下文，因为它们都是协作的一部分。
本文主要选择性地讲解部分协作工具的领域模型，即论坛和共享日历，如下图：

4、身份与访问上下文

现在多数企业级应用程序都需要某种形式的安全和权限组件，这样的组件用以对用户进行认证和授权。正如我们在前面所分析的，一种幼稚的做法就是将这样的组件嵌入到每一个离散的系统中，这将导致每一个系统都产生交筒仓效应(silo effect）。

一个系统的用户并不能轻易地和其他系统的用户发生关联，即便是同一个人使用不同的系统也是如此。为了避免“谷仓”中的粮食溢出到整个业务范围内，架构师需要对安全和权限的管理进行集中化处理。

这构成了一个新的限界上下文——身份和访问上下文。通过标准的DDD集成技术，该上下文可以被其他限界上下文所使用。对于消费份来说，身份与访问上下文是一个通用子域，该产品被命名未IdOvation。

如上图，身份与访问上下文向多租户订阅方提供支持。每一个租户极其拥有的每一个对象资产都有唯一的身份标识，这在逻辑上将不同的租户分离开来。通过基于角色的权限机制来管理对系统资源的获取，这种方式是简单的、优雅的，同时又是功能强大的。

更进一步，当有我们关心的状态由于模型的行为而发生改变时，系统将发布领域事件。这些领域事件通常采用“名词+动词”的形式来命名，动词应该是英文中的过去分词形式，如UserPasswordChanged、tenantProvisioned。

5、敏捷项目管理上下文

敏捷开发提倡一些轻量级方法使其迅速地流行起来。SaaSOvation决定在开发CollabOvation之后再开发一套敏捷项目管理系统。

在过去三个季度中，CollabOvation系统取得了可观的销售业绩，此时公司启动了ProjectOvation项目。这是一个新的核心域，CollabOvation团队中的顶尖人员被调到ProjectOvation项目中以传授DDD经验。

ProjectOvation产品关注于敏捷项目的管理，使用Scrum作为迭代和增量式的项目管理框架。ProjectOvation遵循传统的Scrum项目管理模型，其中包括产品、产品负责人、团队、待定项、计划发布和冲刺等。对待定项的评估通过对业务价值来确定。

CollabOvation和ProjectOvation并不会朝着两个完全不同的方向发展下去。SaaSOvation公司非常看好敏捷软件开发项目中引入协作工具的前景。因此，CollabOvation的功能作为附加服务加到ProjectOvation中，此时CollabOvation便是ProjectOvation的支撑子域。

如上图，在采用战略设计之后，ProjectOvation团队认为软件的消费方应该是产品负责人和产品团队。毕竟，这些才是Scrum参与者所扮演的项目角色。用户和角色在另外的身份与访问上下文中进行管理。通过使用该上下文，订阅者通过自助式的服务来管理他们自己的身份和访问信息。软件的管理使得项目管理者，比如产品负责人确定项目的团队成员。在角色管理适当的情况下，产品负责人和团队成员都可以在敏捷项目管理上下文中创建。

基于SaaSOvation开发团队所获得的经验，ProjectOvation的核心域已经开始开发了，该核心域包含产品、产品负责人、团队、待定项、计划发布和冲刺等。