领域驱动设计学习:上下文映射图

前面一篇文章介绍了限界上下文的概念和部分相关内容,那么,上下文之间的关系怎么表示呢?答案就是这篇文章要介绍的——上下文映射图(Context Map)。

概念:

上下文映射图就通过画图的方式展示N(N>=2)个上下文之间的映射关系。

上下文组织和集成模式的定义:

上下文有如下组织和集成模式的定义:

图1:上下文组织和集成模式种类

合作关系:

如果两个限界上下文的团队要么一起成功,要么一起失败,那么他们就需要建立起合作关系。两个团队应该在接口的演化上进行合作以同时满足两个系统的需求。应该为相互关联的软件功能制定好计划表,这样可以确保这些功能在同一个发布中完成。

共享内核:

对模型和代码的共享将产生一种紧密的依赖性。我们需要为共享的部分模型指定一个显示的边界,并保持共享内核的小型化。共享内核具有特殊的状态,在没有与另一个团队进行协商的情况下,这种状态是不能改变的。

客户方-供应方开发:

当两个团队处于一种上游-下游的关系时,上游团队的计划中应该顾及到下游团队的需求。

遵奉者:

在存在上游-下游关系的两个团队中,如果上游团队已经没有动力提供下游团队之所需,下游团队便孤立无援了,只能盲目使用上游团队的模型。

防腐层:

就是上下游之间的翻译层,放在下游上。对于下游客户来说,你需要根据自己的领域模型创建一个单独的层,该层作为上游系统的委派向你的系统提供功能。防腐层通过已有的接口与其他系统交互,而尽量使其他系统无需修改。在防腐层内部,它在你自己的模型和他方模型之间进行翻译转换。

开放主机服务:

定义一种协议,让你的子系统通过该协议来访问你的服务。

发布语言:

在两个限界上下文之间翻译模型需要一种共享的公用的语言。发布语言通常和开放主机服务一起用。

大泥球:

当我们检查已有系统时,经常会发现系统中存在混杂在一起的模型,它们之间的边界是非常模糊的。此时你应该为整个系统绘制一个边界,然后将其归纳在大泥球之列。

书中其实还提到不需要集成时可以声明两个限界上下文之间没有任何关系,这样使得开发者去寻找另外、简单的方法来解决问题。

作图方式示例:

图2:示例图

ACL表示防腐层,OHS表示开放主机服务,PL表示发布语言,U代表上游,D代表下游。

部分集成模式涉及到的技术:

开放主机服务:

该模式可以通过REST实现。通常来讲,我们可以将开放主机服务看作是远程过程调用(RPC)的API。同时,也可以通过消息机制实现。

发布语言:

最常见的是使用XML Schema。在使用REST时,发布语言用来表示领域概念,此时可以用XML和JSON。发布语言还可以用于事件驱动架构(EDA),其中,领域事件以消息的形式发送到订阅方。

防腐层:

在下游上下文中,我们可以为每个防腐层定义相应的领域服务。同时,你也可以将防腐层用于资源库接口。在使用REST时,客户端的领域服务将访问远程的开放主机服务,远程服务器以发布语言的形式返回,下游的防腐层将返回内容翻译成本地上下文的领域对象。

参考资料:

1、《实现领域驱动设计》(书)

猜你喜欢

转载自blog.csdn.net/jspyth/article/details/83216767