第14章 Bounded Context, 这章还没读前，《build microservices》这本书就提到了它，引用了很多限定上下文的概念和描述；上周的Pivotal介绍会上，讲师也反复提到这个概念。这些都让我在读之前对这章内容充满了期待...
本章介绍了一些用于识别、沟通和选择模型边界及关系的技术，这些技术，作为微服务的划分考虑基础再合适不过了。Bounded Context 定义了每个模型的应用范围，而Context Map则给这些上下文关系提供了整体视图，本章里的模式提供了方法来处理不同上下文关系，逐渐将模型定义清楚，实现整个项目的灵活性和集成性，这个可以通过本书的模型完整性模式导航图，按图索骥逐个了解。
让我颇为受益或者给与触动的有如下两段描述：
1. 开发统一的系统需要维持高超的沟通水平，虽然意识到了重复的概念和行为需要统一，但却因为担心破坏现有功能而不敢去改动他们，于是继续在多处重复开发
2. 多个模型看上去不雅致，对多个模型的抵制心理，会试图“极富雄心”地统一到单一模型
向右走，选择较小的Bounded Context。开发人员沟通开销低，CI更容易，在技巧人员短缺时，方便用不同模型满足特殊需求；向左走，选择较大的Bounded Context, 要找到统一模型。可以减少多模型间的边界转换映射，而且共享语言可以使团队沟通起来更清楚。
我们是向左走还是向右走？合并系统其实本质在做统一模型，它的合适度在哪里？
4PL, DCS, OCS这些系统合用了一个SVO-SVR的模型，这样shared kernal对吗？如果要分开模型，它的shared kernal是不是应该转向common order相关的milestone, exception这些模型？
为了避免重复造轮子，我们习惯于在现有系统里找到相似模型后，进行功能扩展。是不是一开始我们就应该考量下新问题的Bounded context 与原系统模型的上下文是否一致？
本章节中，盲人摸象的例子，读来饶有趣味。它很形象地说明了集成在一起的bounded context 是可以协调工作，让大象起舞的。这个章节值得再读，特别在碰到改造遗留系统，设计新系统，或者连接新系统与遗留系统等问题时。
