[转载]IDDD 实现领域驱动设计-上下文映射图及其相关概念 - 田园里的蟋蟀 - 博客园

baacloud免费翻墙vpn注册使用

[转载]IDDD 实现领域驱动设计-上下文映射图及其相关概念 – 田园里的蟋蟀 – 博客园.

上一篇:《IDDD 实现领域驱动设计-理解限界上下文

距离上一篇有几天时间了,《实现领域驱动设计》第三章的内容都是围绕一个词-上下文映射图,我大概断断续续看了几天,总共看了两遍,但模模糊糊也不 是很理解,不像前两章有一个可以触动我的地方,但有很多概念是蛮重要的,这篇没有自己的理解,大部分都是整理上下文映射图及其相关概念。


可以看作是示例上下文,大家在画上下文映射图的时候可以参照一下,后面的大部分概念,也都围绕它展开。

  • 上下文映射图(Context Map):可以进行拆分理解,上下文指的就是限界上下文,映射的意思就是关联、联系,就像 ORM 中,对象与关系的映射,图就是把限界上下文之间的关联与联系表现出来,具体的展示就是类似上面的图。
  • 合作关系(Partnership):如果两个限界上下文的团队要么一起成功,要么一起失败,要么一起 成功,此时他们需要建立起一种合作关系。他们需要一起协调开发计划和集成管理。两个团队应该在接口的演化上进行合作以同时满足两个系统的需求。应该为相互 关联的软件功能定制好计划表,这样可以确保这些功能在同一个发布中完成。
  • 共享内核(Shared Kernel):对模型和代码的共享将产生一种紧密的依赖性,对于设计来说,这种依赖性可好可坏。我们需要为共享的部分模型指定一个显式的边界,并保持共 享内核的小型化。共享内核具有特殊的状态,在没有与另一个团队协商的情况下,这种状态是不可改变的。我们应该引入一种持续集成过程来保证共享内核和通用语 言的一致性。
  • 客户方-供应方开发(Customer-Supplier Development):当两个团队处于一种上游-下游关系时,上游团队可能独立于下游团队完成开发,此时下游团队的开发可能会受到很大的影响。因此,在上游团队的计划中,我们应该顾及到下游团队的需求。
  • 遵奉者(Confoemist):在存在上游-下游的关系的两个团队中,如果上游团队已经没有动力提供 下游团队之所需,下游团队便孤立无援了。出于利于他主义,上游团队可能向下游团队做出种种承诺,但是有很大的可能是:这些承诺是无法实现的。下游团队职能 盲目的使用上游团队的模型。
  • 防腐层(Anticorruption Layer):在集成两个设计良好的限界上下文时,翻译层可能很简单,甚至可能很优雅的实现。但是,当共享内核、合作关系或客户方-供应方关系无法顺利实 现时,此时的翻译将变得复杂。对于下游客户来说,你需要根据自己的领域模型创建一个单独的层,该层作为上游系统的委派向你的系统提供功能。防腐层通过已有 的接口与其他系统交互,而其他系统只需要做很小的修改,甚至无须修改。在防腐层内部,它在你自己的模型和他方模型之间翻译转换。
  • 开放主机服务(Open Host Service):定义一种协议,让你的子系统通过该协议来访问你的服务。你需要讲该协议公开,这样任何想与你集成的人都可以使用该协议。在有新的集成需 求时,你应该对协议进行改进或扩展。对于一些特殊的需求,你可以采用一次性的翻译予以处理,这样可以保持协议的简单性和连贯性。
  • 发布语言(Published Language):在两个限界上下文之间翻译模型需要一种公用的语言。此时你应该使用一种发布出来的共享语言来完成集成交流。发布语言通常与开放主机服务一起使用。
  • 另谋他路(SpeparateWay):在确定需求时,我们应该做到坚决彻底。如果两套功能没有显著的关系,那么它们是可以被完全解耦的。集成总是昂贵的,有时带给你的好处也不大。声明两个限界上下文之间不存在任何关系,这样使得开发者去另外寻找简单的、专门的方法来解决问题。
  • 大泥球(Big Ball of Mud):当我们检查已有系统时,经常会发现系统中存在混杂在一起的模型,它们之间的边界是非常模糊的。此时你应该为整个系统绘制一个边界,然后将其归纳 在大泥球范围之列。在这个边界之内,不要尝试使用复杂的建模手段来化解问题。同时,这样的系统有可能会向其他系统蔓延,你应该对此保持警觉。
作者:田园里的蟋蟀
出处:http://www.cnblogs.com/xishuai/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接。
赞(0) 打赏
分享到: 更多 (0)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏