一个典型的上下文映射图
映射图可以反映 哪些地方需要与其他团队进行交流。
上下文映射展示团队之间边界。促进不同团队之间的交流。
跨团队协作避免出现： 客户方、供应方的关系。
如果对方团队决定维持现状，你的团队陷入尊奉者，被动处理的情况，实践中，尽量避免，你可以借助外力，或者寻找合适的机会，把技术包袱巧妙的处理掉。
你需要识别出项目中每一个模型并确定好他的界限上下文， 每个界限命名。该名字应该是通用语言的一部分。描述模型直接的连接点，并将模型之间的翻译转换成显示的勾勒出来。
上下文映射图表现的是项目当前的状态，若项目发生变化，你可以到那时才对上下文映射图做出相应的更新。
上下文映射图并不复杂，也不需要那么正式
上下文映射图，并不是一种企业架构，也不是系统拓扑图，
上下文更多的展示一种组织动态能力 organizational dynamic
可以帮助我们识别出有碍项目进展的一些管理问题，上下文映射图更多的是 项目管理者绘制，维护。
统一的命名规则，最好有产品牵头负责。
上下文映射图，需要展现在显眼的位置，wiki 的首页。
上下文的关系
合作关系 partnership
两个上下文要么一起成功，要么一起失败，建立了一种合作关系，需要一起协调开发计划。P80
共享内核 Shared Kernel
对模型和代码的共享将产生一种紧密的依赖性，对于设计来说，这种依赖性可好可坏。我们需要为共享的部分模型指定一个显示的边界，兵保持共享内核的最小化。共享内核具有特殊的状态，在没与另一个团队协商的情况下，这种状态是不能改变的，我们应该引入持续化集成的过程来保证共享内核与通用语言等一致性。
典型的例子是 一个客户管理系统和一个商城共享一个 企业资料模型，这时候尽可能的控制共享的模型。
客户方-供应方开发（Customer-Supplier Development）
两个团队处于上下游关系，上游团队独立于下游团队完成开发，此时下游的团队开发会受到影响。
实践中，对于上下游的开发，尽量避免作为下游的团队，除非你的上游团队和你有良好的合作关系。
尊奉者 Conformist
上下游关系两个团队中，上游团队已经无意愿，无动力为下游提供接口，这时候下游只能按照上游既有接口或者思路对接，
这种关系需要极力避免，或者明确各自的权责。
防腐层 Anticorruption Layer
对于上下游关系，下游需要根据自己的领域模型创建一个单独的层，避免自己的其他系统做大的修改，一般适用于外部系统对接的时候。
例如，银行的资产系统风控系统需要对接外部供应商的信用查询接口，供应商很多，接口各异，你需要单独设置一个对阶层，处理外部系统的变化，将外部系统的数据模型转换成内部统一的数据模型
开放主机服务 open host service ：
定义一种协议，让你的子系统通过该协议访问你的服务。你需要将该协议公开，这样任何与你集成的人都可以使用该协议。
个人理解：这种协议算是一个约定的接口，技术角度不会自定义一种远程访问协议。
发布语言 Published Language
和开放主机服务一起，例如json 或者xml 或者自定义文档返回格式（个人理解，欢迎交流）
另谋他路
大泥球
在使用远程调用时，注意远程服务返回的对象和本地对象的转换，
在实践中，赶工期的时候会导致对象的过度重用，限制代码的灵活性。
小结：上下文映射如图 主要解决团队交流协作问题
适合业务复杂的分布式项目设计时运用。