能力映射和上下文映射

原文：https://medium.com/hackernoon/capability-mapping-and-context-mapping-95cf862f0753

上下文映射至少解决了两个问题。

第一个是 概念完整性,神话人月的作者 Frederick Brooks 认为在设计和维护任何系统时要记住的主要事情。每个开发人员都知道每一个更高层次的部分，并意识到它基本上是做什么的。每个开发人员都有他或她正在使用的模型的适用性边界的视觉图像。人们可以对其他模型中适用的内容有所了解。最后，我们可以看到上下文是如何相互联系的。

第二个是 管理型 。通常一个团队参与一个或多个上下文。真正需要一个以上团队的大环境很少。所以，一般来说，团队是根据上下文来组织的。因此，上下文映射有助于可视化团队之间的关系，从而产生上下文关系。一个上下文的 API 会适应另一个上下文的 API 吗？一个上下文会实现另一个上下文需要的功能吗？他们之间的关系是客户/供应商吗？或者他们中的一个必须成为一个循规蹈矩的人？所有这些问题都反映了一个公司的政治环境和组织关系。并且应该发现相应的答案——越早越好。

能力映射+上下文映射=成功组合

至少有两个问题是能力映射补充了上下文映射。

第一个是关系。虽然上下文映射给出了组织关系的概念，但它不会告诉这些上下文如何相互通信。此功能映射成功。

第二个问题可能是对有界语境概念的错误理解的结果。我总是发现，有界的上下文不存在于 嵌套的概念 的事实限制了我的整体系统观，我对系统的更高层次的理解。有界的上下文没有被描绘成嵌套的，可能是因为上下文映射强调组织结构方案，其中一个团队是不可分割的项目。或者这可能是有界环境被理解为物理边界的结果，我不知道。无论如何，仅仅使用上下文映射很难理解企业的运作方式。

同时，功能映射服务可以相互嵌套。这就像一个更粗粒度的功能由更细粒度的功能组成，具有清晰的通信方案。

从另一方面来说，我认为上下文映射的实现方式是有意选择的。上下文映射没有过载，看起来很好。它代表了不同背景下的团队之间的关系——而且做得很好。让它成为它的责任，让业务能力映射有一个专门的操作焦点。