最近发现下面关于上下文的理解有些问题，不太好改，暂时先不改了
承前：大型系统的支撑，应用系统开发思想的变迁，DDD实践切入点(一)
从大比例结构入手已经开始了系统的建设，大家都知道需求是会不断变化不断深入的，刚开始自然是模糊的大比例结构对将要进行的系统有一个初步的认识，在不断细化的过程中明确需求。前一篇中粗略的对主要的问题进行了描述，可以看出主要有两个部分，申请单管理和审批流转，两者都与申请单关联，但关注点不同，申请单管理的重点是对申请单本身信息的维护，而审批流转中主要是以申请单的部分信息为依据进行流转的决策，所以两者申请单的模型有些许不同。
领域模型不统一时，会有一些问题，比如：限制了集成，增加沟通成本，看上去不优雅。但大型系统领域模型完全统一并不是一种可行的经济有效的做法。强行统一模型会遇到一些问题：
1.遗留系统模型的修改过多，风险很大；
2.协调多个小组所使用的不同模型使之统一时成本过高，开销过大；
3.具有一些特殊需求的模块可能不得不使用无法充分满足需求的模型，而只能讲这些无法满足的行为放到其他地方；
4.试图用一个模型满足所有人需求可能会导致模型中包含过于复杂的选择，难以使用。
是以统一模型的方式并不是一个好办法，在这种情况下，需要标记出不同模型之间的边界和关系。Bounded Context（界限上下文）即是用来定义每个模型的应用范围，上下文图则用来给出项目上下文以及他们之间关系的总体视图。申请单管理和流程流转就可以两个Context来分别开发。需要注意的是，这样做会引发一些问题：重复的概念和假同源。重复的概念是两个模型元素表示的实际是同一个概念，每当概念变化时，都必须修改两个地方。假同源是指对不同的概念使用了相同术语。这些情况多是由上下文边界不清晰造成的。
上下文图可以使上下文的边界清晰，需要注意上下文之间的代码尽量不要重用，相邻上下文不必保持同样步调，上下文之间的集成需要通过接口或经过转换实现。识别每个模型在项目中的作用，并定义其Bounded Context。包括非面向对象子系统的隐含模型。为每个Bounded Context命名，并把名称添加到通用语言中。描述模型之间的接触点，明确每次交流所需的转换，并突出共享的内容。
图中没有共享内容，只是申请单将流转所需条件信息和流转任务委托给流程进行处理，条件信息中包含流转所必须的申请单的模型，但此申请单模型和单据上下文中的申请单模型有些不同，这个不细说了。此处只是信息单向传送，如果有交互时，中间的流转条件需要做双向的信息转换。此外，通常多个模型在集成时可能会遇到一些障碍，有一些现成的模式用来解决这些障碍，例如：共享核心，跟随者，隔离层，Separate Way(独立自主)，Open Host Service，Published Language，这些模式都是随情况而定的，或许之后在具体情况遇到时会细说，这里就不抄书了。随着项目的进行，这些模式的选择，上下文图的组织方式都有可能发生转变。这种转变的过程中也可以借助大比例结构以及精炼核心领域划分通用子领域的方式来管理模型的复杂性。精炼的一些模式有缘的话我可能会单独整理一下，因为这次只用到了一个抽象核心，所以就在之后和其他过程一起介绍，不单独说了。