《实现领域驱动设计》笔记——上下文映射图

一个项目的上下文映射图可以用方式来表示。比较容易的一种是画一个简单的框图表示两个或多个限界上下文之间的映射关系。该框图表示了不同的限界上下文在解决方案空间中是如何通过集成相互关联的。另一种更详细的方式是通过限界上下文集成的源代码实现来表示。

　　上下文映射图为什么重要

　　上下文映射图主要帮助我们从解决方案空的角度看待问题。

　　假定你期望大泥球维护团队提供一套新的 API。然而，他们却并不打算这么做，或者他们根本就不知道你的想法。此时你的团队和大泥球维护团队的关系变成了 客户方-供应方 的关系。由于大泥球团队决定维持现状，你的团队不得不陷入一种遵奉着关系中。这样的关系可能导致你的项目延期交付或者彻底失败。

　　尽早绘制上下文映射图，这样可以迫使你仔细思考你的项目和你所依赖项目之间的关系。

　　绘制上下文映射图

　　上下文映射图表现的是项目当前的状态，如果项目会在将来发生改变，你可以到那时才对上下文映射图做出相应的更新。关注于当前的项目状态可以帮助你了解你正处的位置，并帮助你决定如何走出下一步。

　　绘制一个上下文映射图并不复杂。通常，首选在白板上手绘映射图，此时你可以采用 [Brandolini] 的风格。如果你打算使用一个绘图工具来绘制上下文映射图，请注意不要把图画得太正式了。

　　上图 3.1 中，图中限界上下文的名字和彼此之间的集成关系只是占位符而已，在真实的上下文映射图中，我们将代之以实际的名字。

　　有时，我们希望对上下文映射图的某些特定部分进行放大，以向里面加入更多的细节，这只是从另外一个角度来看待同一个限界上下文。除了边界、关系和翻译，我们可以可能希望加入其他的一些内容，比如模块、聚合，或者团队的分布信息等。

　　所绘制的所有映射图，包括文字，都可以装订在同一份参考文档中，只要这对团队是有价值的。在这个过程中，我们应该避免那些繁文缛节性的仪式，保持简单和敏捷。向框图中加入过多的细节对团队并无多大帮助，交流才是关键，我们应该将交流对话也加入到上下文映射图中。

　　上下文映射图并不是一种企业架构，也不是系统拓扑图。但是，它可以用于高层次的架构分析，指出诸如集成瓶颈之类的架构不足。上下文映射图展现了一种组织动态能力，它可以帮助我们识别出有碍项目进展的一些管理问题。

　　并不是说限界上下文边界一定得密不透风，而是：对于任何上下文边界，开发团队都希望协作上下文能够完全地控制所进所出，还包括进出的原因。否则，该上下文便会出现一些不受欢迎的“拜访者”。对于模型而言，这些“拜访者”通常会导致混淆和 BUG。建模人员应该是友好的，但是友好的前提是秩序与和谐。任何进入边界的外部概念都应该持有充分的理由，甚至需要和边界内的模型保持良好的兼容性。

　　在理解充分的情况下，要绘制上下文映射图并不难，但是通常来说，我们并不会将映射图中的所有内容都显示出来。在迭代过程中，思考和讨论可以帮助我们改进上下文映射图，比如对集成点进行改进，这将有助于描述限界上下文之间的关系。

　　拥有自治服务的应用程序并不表示需要将上游系统的数据库复制到下游系统。数据库复制将迫使本地系统承担过多的职责，它需要创建一个共享内核，而这并不是真正意义上的自治。

　　处理不可用的一个 好办法是将其显现出来。

　　使用资源可用性状态的好处并不只是技术上的，还有商业上的。

　　需要记住的是，对于一个非常详细的上下文映射图，我们很有可能无法对其进行实时更新。

文章转载自：Ruby_Lu

原文链接：https://www.cnblogs.com/afei-24/p/17848031.html