目录
3.2.3 客户方－供应方开发（Customer-Supplier Development）：
3.2.4 防腐层（Anticorruption Layer）：（重点）
3.2.5 开放主机服务（Open Host Service）：（重点）
3.2.6 发布语言（Published Language）：（重点）
01. 什么是上下文映射图？
上下文：限界上下文，
映射：关联、联系
图：图。
上下文映射图：用图的方式，表达出限界上下文之间的关联。
02. 为什么要有上下文映射
设计的目的：
降低业务复杂度
有效手段：分治法
DDD的分治：
子域 & 限界上下文
分是合的基础 隔离是复用的前提
限界上下文最终要合在一起提供领域服务，限界上下文之间怎么合： 上下文映射
“合”就是要尽可能地降低 不同上下文 之间的耦合。
意义：
解决限界上下文之间的协作问题。
展现组织动态能力，帮助识别有碍项目进展的管理问题。
03. 绘制上下文映射图
3.1 上下游
我们用Upstream的首字母U来标识“上游”，用Downstream的首字母D来标识“下游”。那怎么去判断“上游”还是“下游”呢？这里有一个原则：下游的模型依赖于上游的模型和服务。
3.2 映射的种类：
3.2.1 合作关系（Partnership）：
如果两个限界上下文的团队要么一起成功，要么一起失败，要么一起成功，此时他们需要建立起一种合作关系。他们需要一起协调开发计划和集成管理。两个团队应该在接口的演化上进行合作以同时满足两个系统的需求。应该为相互关联的软件功能定制好计划表，这样可以确保这些功能在同一个发布中完成。
- 共同成功 OR 共同失败
- 合作
- 协调开发计划
- 协调集成管理
- 接口演化的沟通
- 共同的计划表
- 共同的发布计划
3.2.2 共享内核（Shared Kernel）：
对模型和代码的共享将产生一种紧密的依赖性，对于设计来说，这种依赖性可好可坏。我们需要为共享的部分模型指定一个显式的边界，并保持共享内核的小型化。共享内核具有特殊的状态，在没有与另一个团队协商的情况下，这种状态是不可改变的。我们应该引入一种持续集成过程来保证共享内核和通用语言的一致性。
两个（或更多）团队之间共享着一个小规模但却通用的模型。团队必须就要共享的模型元素达成一致。有可能它们当中只有一个团队会维护、构建及测试共享模型的代码。共享内核通常一开始很难理解，也很难维护，这是因为团队之间的沟通必须完全开放，而且他们必须就共享模型的构成不断地达成一致。但是，只要所有参与者都认同共享内核比各行其道的方式更好，就有可能获得成功。
- 双方对共享模型代码依赖紧密
- 共享部分尽可能小，需要制定一个显式的边界
- 双方都知晓的情况下才能改变共享内核状态
- 引入持续集成保证质量
3.2.3 客户方－供应方开发（Customer-Supplier Development）：
当两个团队处于一种上游－下游关系时，上游团队可能独立于下游团队完成开发，此时下游团队的开发可能会受到很大的影响。因此，在上游团队的计划中，我们应该顾及到下游团队的需求。
- 上下游关系
- 下游依赖上游
- 上游照顾下游需求
3.2.3 遵奉者（Confoemist）：
在存在上游－下游的关系的两个团队中，如果上游团队已经没有动力提供下游团队之所需，下游团队便孤立无援了。出于利于他主义，上游团队可能向下游团队做出种种承诺，但是有很大的可能是：这些承诺是无法实现的。下游团队也无法投入资源去翻译上游模型的通用语言来适应自己的特定需求，因此只能顺应上游的模型。
- 上下游关系
- 上游没有动机为下游提供需求
- 下游顺应上游模型
如，当一个团队需要与一个非常庞大复杂的模型集成，而且这个模型已经非常成熟时，团队往往会成为它的跟随者。
3.2.4 防腐层（Anticorruption Layer）：（重点）
防腐层（AnticorruptionLayer）是最具防御性的上下文映射关系，下游团队在其通用语言（模型）和位于它上游的通用语言（模型）之间创建了一个翻译层。防腐层隔离了下游模型与上游模型，并完成两者之间的翻译。所以，这也是一种集成的方式。
但凡有可能，你就应该尝试在下游模型和上游集成模型之间创建一个防腐层，这样才可以在你这端的集成中创造出特别适合业务需求的模型概念，并将外部概念完全地隔离。然而，就像为两个讲不同语言的团队雇佣翻译来解决沟通问题一样，在某些情况下各方面的成本会水涨船高。
3.2.5 开放主机服务（Open Host Service）：（重点）
定义一种协议，让你的子系统通过该协议来访问你的服务。你需要将该协议公开，这样任何想与你集成的人都可以使用该协议。在有新的集成需求时，你应该对协议进行改进或扩展。对于一些特殊的需求，你可以采用一次性的翻译予以处理，这样可以保持协议的简单性和连贯性。
- 一套开放的协议 / 接口 —— REST，RPC ....
- 使用简单
- 有详细文档，可供他人集成
3.2.6 发布语言（Published Language）：（重点）
是一种有着丰富文档的信息交换语言，可以被许多消费方的限界上下文简单地使用和翻译。需要读写信息的消费者们可以把共享语言翻译成自己的语言。
这种已发布语言可以用XML Schema、JSON Schema或更佳的序列化格式定义。通常，同时提供和使用已发布语言的开放主机服务可以为第三方提供最佳的集成体验。这种结合使得两种通用语言之间的转译非常方便。
- 有文档信息的交换语言
- 消费方可翻译
- XML / JSON / .... 序列化形式
- 通常和OHS一起使用
3.2.7 另谋他路（SpeparateWay）：
在确定需求时，我们应该做到坚决彻底。如果两套功能没有显著的关系，那么它们是可以被完全解耦的。集成总是昂贵的，有时带给你的好处也不大。声明两个限界上下文之间不存在任何关系，这样使得开发者去另外寻找简单的、专门的方法来解决问题。
- 放弃集成
- 自己做
3.2.8 大泥球（Big Ball of Mud）：
当我们检查已有系统时，经常会发现系统中存在混杂在一起的模型，它们之间的边界是非常模糊的。此时你应该为整个系统绘制一个边界，然后将其归纳在大泥球范围之列。在这个边界之内，不要尝试使用复杂的建模手段来化解问题。同时，这样的系统有可能会向其他系统蔓延，你应该对此保持警觉。
扫一扫
1749
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
