DDD上下文映射之间的带宽 - Mathias


上下文映射,最早是由Eric Evans在领域驱动设计中描述的,是一种轻量级的方法,用来描述系统和系统的一部分之间的关系。

它本身不是技术性的。它暴露了组织的政治和构建系统的团队。
当你开始绘制时,连接两个系统的每条边都定义了一个上游和一个下游点;后者是受前者变化影响的系统。
或者,说得更形象一点:如果上游的人在河里撒尿,下游的人就会喝下它。
请原谅我的语法。
在这本书中,埃里克定义了一些模式,来描述这些关系:
反腐败层,定制/供应商,开放的主机服务,发布的语言,共享的内核,等等。

请注意,这与数据的方向无关。您可能正在将数据发送到另一个系统,但仍处于下游,因为它们决定了数据的外观。Eric 和Alberto Brandolini已经解释得比我好,所以我不会详细说明。
在今天的研讨会和晚宴上,Alberto Brandolini解释了他最近关于带宽的想法。

对我来说,这将整个上下文映射联系在一起:
当你画一个上下文图时,你会把系统的不同的有边界的上下文可视化。
这当然是很有用的信息,特别是在处理一个遗留系统的时候。

对于未经训练的眼睛来说,它实际上不仅仅是一个静态的表示。
在各部分之间的空白处,有关于项目未来成功的隐含信息:假设你是另一个团队的系统的下游。你把这种关系在你这边标注为顺应者。现在有人想让你做一个重大的改变,而这个改变触及到与上游系统的这种关系。这个项目会成功吗?

你不能只看上下文图就回答这个问题。一些缺失的概念隐藏在空白处。
上下文映射模式描述了沟通的特点,但没有描述两个团队之间有多少沟通在进行。
Alberto把这个数量命名为 "带宽":

带宽会对你产生很大影响。如果上游团队在不同的国家,而你每月只和他们打一次电话,那么带宽就会很低。
如果他们在隔壁的办公室,而你每天与他们共进午餐,你的带宽就会更高。

尽管在我的例子中,你主要是顺从者,但你仍然有机会稍微改变这种关系,也许会把它推向客户/供应商模式的方向。

带宽允许更多的交流,更多的机会分享理解,更多的机会对他们提供的服务至少有一些发言权。

许多事情都会影响带宽:明显的事情,如实际可用性、沟通频率、响应速度......但也有一些事情,如资历:在组织中呆了很长时间的人,通常是制定规则的人。

有时,这将由哪个系统对业务更重要来决定,尽管在某些情况下,一个不太重要的系统可能仍会发号司令。
如果有一个系统是遗留的,那么它将是上游的,仅仅是因为它太难改变了。
也可能是上游团队太过自负,不愿意与其他团队产生共鸣。

通过画出更大和更小的边缘,使带宽明确化,有助于你做出更明智的决定。
低带宽意味着项目的高风险,因为这些项目依赖于有界上下文之间的沟通。

有了带宽,上下文图就更完整了:它现在显示了结构、关系的特点和沟通的数量。