实现领域驱动设计-上下文映射图

上下文映射图就是表示两个或多个限界上下文之间的映射关系。

一般用框图表示，不同的限界上下文在解决方案空间中是如何通过集成相互关联的。

两个上下文之间有什么关系呢？

合作关系（Partnership），共同成功，共同失败。现在mbox的file和owner服务应该就属于合作关系，共同为api服务。

共享内核（SharedKernel），模型和代码的共享将产生一种紧密的依赖性，比如用jar内定义了thrift共享的领域对象

客户方-供应方开发（Customer-Supplier Development），客户方提需求，供应方配合做开发，现在用mq解耦的方式就非常类似这种

尊奉者（Conformist），跟客户方-供应方开发类似，只是供应方没有开发功力，完成由客户方-即尊奉者-自己按照供应能提供的现有的东西做开发，这时候对尊奉者来说，难度是比较大的

防腐层（Anticorruption Layer），简称ACL，在集成两个上下文，如果两边都状态良好，可以引入防腐层来作为两边的翻译，并且可以隔离两边的领域模型，现在的api网关和facade层，就是防腐层的概念

开放主机服务（Open Host Service），简称OHS，公开发布服务，公开的http服务，这是经常使用的

发布语言（Published Language），简称PL，在两个限界上下文之间翻译模型需要一种公用的语言，发布语言通常与开放主机服务一起使用。比如http服务，使用xml交互还是json做数据格式

另谋他路（SeparateWay），声明两个限界上下文不存在任何关系，这也是一种很重的关系，完全独立各自开发

大泥球（Big Ball of Mud），对已有的一个大的混杂的系统，已经无法在内部梳理清楚了。你那怎么办呢？把这整个系统当成一个大泥球，对整个系统画在一个边界内，当成一个黑盒子，这样只要接口可用就行，也防止了大泥球内部的混杂扩展到其它系统上。对历史包袱的系统，可以采取这种做法。

其中ACL，OHS，PL，CSD是经常使用的。

一个典型的上下文映射图：