该文是事件风暴创始人Alberto最新文章，谈论了DDD中有界上下文BC划分与团队组织划分方式是两种不同目标方式，不能简单一个DDD有界上下文对应一个微服务对应一个团队，而是在对业务知识深入理解学习过程中随着BC或微服务动态调整团队大小，不可能一劳永逸在项目开始之初就能确定好团队组织结构。
正如Matthew Skelton和Manuel Pais所著的书中所描述的那样，团队拓扑的概念正受到全世界的关注。对团队结构和目标的关注引起了有趣的讨论，许多组织正在采用该模型作为其开发团队组织的参考。
同时，由于问题空间似乎与上下文映射的某些高级概念重叠，因此领域驱动设计从业人员也有种似曾相识的感觉。这是我尝试了解两全其美并了解不同方法的利弊的尝试。
问题空间主要是未知领域
大多数组织有机地增长，在积压的压力下规模不断扩大。规模不断壮大的团队将不得不分裂，能力将变得更加狭窄和专业化。然而，标准的划分方法（即使不是很多）已经被议论不休，到底是围绕业务能力划分还是周围技术技能划分？结果是永远不会完美，留给决策者的感觉，也许另一种方法本来可以更好...
更糟糕的是，每个组织都将调整团队和组建团队的责任交到不同的人手中：这是团队领导者的责任，还是开发负责人？还是CTO？为此，我们需要特定的角色吗？我们是否总是需要升级到生态系统级别，还是团队之间的协作只是一个本地问题？
你被spotified了吗？
缺乏参考模型也说明了Spotify模型的流行：一个在团队模型和协作模型上尝试不同模型的组织迅速成为灵感的来源，并带来了许多意想不到的后果。像精益和丰田一样，其他人也遵循该模型，而没有过多地关注使该模型在特定环境下可行的要素。
简而言之，大多数无关紧要的软件开发组织在此领域都会遇到某种摩擦。软件团队之间的协作是成功公司的关键基本特征之一，但是无摩擦协作似乎是一种幻想，因此，如果IT专业人员寻求指导，这并不奇怪。
团队拓扑分类
团队拓扑描述了四种团队类型：
- 基于流程协调的团队专注于特定的业务能力，理想情况下是跨职能的；
- 平台团队为其他团队提供公共服务；
- 复杂的子系统团队一支高度专业化的团队，并且对系统的一部分有特定的了解；
- 支持团队的专家团队，指导和帮助其他团队发展和改进。
尽管这些概念并不新鲜-它们源于对许多不同生态系统的观察-有趣的是，它们提供了词汇表和一些参考模型。您可能希望将此原型列表视为吸引优秀团队的吸引者，但同时请注意，它们只是四个！
您的组织正在做的一些奇怪的事情未在此处列出，也许是有充分的理由的。这些是运作良好的团队的参考实现。
三种互动模式
据团队之间的关系，描述了三种模式：
- Collaboration 协调：当两个团队紧密合作以实现共同目标时进行协作；
- X - as a service 某个东西作为服务：在使用方面有联系的情况下即服务，但很少有具体的协作；
- Facilitation 便利：一个团队正在帮助一个团队摆脱障碍。
四种团队类型与三种互动方式如下图：
上下文映射模式
战略性领域驱动设计提供了关于相同问题空间但结构不同的有趣观点。
几乎没有明确提及团队，但主要假设是在中型软件组织中，这两个概念之间存在紧密的映射关系，因此重点主要放在有界上下文上。
是有界上下文团队吗？
不，有界上下文的定义类似于给定模型的适用范围。但是，只有当一个团队负责模型的给定部分，并在整个社会技术体系中建立联系（与业务代表交谈）时，才能进行复杂的领域理解，这是领域驱动设计的基本要素。并测试代码，与用户互动等）。
DDD社区对此有一些公认的智慧，让我们明确一点。
- 一个团队对应多个有界上下文
一个团队可以管理多个BC吗？是的，这通常是小型组织的规范。
但是，好吧……大多数小型组织似乎对边界分离不太在意。实际上，实现良好分离的唯一方法是显式实施分离：从大型可见映射到代码库分离。
实际上，最难管理的是相关开发人员的认知负担。您一次只能深入了解一个模型。尽管一个团队可以建立许多模型，但您必须非常善于明确界限。
- 更多的团队对应一个有界上下文
我们可以有两个团队在同一个模型上工作吗？显然，是的。我的意思是：绘图似乎很简单。不幸的是，在相同界限上下文下工作的两个团队通常是骚乱的前奏。团队通常有不同的积压和优先级，歧义会迅速在代码库中腐烂，从而加速向“大泥巴”的过渡。通常，您不会拥有如此庞大的BC，足以证明有多个团队在为他们工作。所以不行。
有趣的是，Spotify模型在该方向上有所发展，放宽了代码库的所有权，以降低协调成本（再次是通信带宽），同时减轻了采用强大的工程实践而降低质量的风险。但是，它们没有BIG共享的有界上下文，而是许多具有宽松所有权规则的较小的上下文。
- 一个团队对应一个有界上下文
理想的选择似乎是在有限的范围内规定一支团队参与。
但是一些细节被遗漏了。例如组织规模。上次检查时，我在内部软件中计算了20种不同的有界上下文。这是否意味着我们需要20 *（7±2）个开发人员来编写我们的软件？对于一家5人的公司？Come on！
但是规模并不是这里唯一的问题：不同的BC并非以相同的速度发展，相同的将会增长。另一个会稳定下来，理想情况下会长时间保持不变，但是闲置团队的概念在企业中并不那么流行，一个风险是因为团队填满了积压的订单。团队与有界上下文之间的关联是暂时的，并且会随着时间而变化。
协作模式
上下文映射的重点不是团队的外形大小形状，而是必须支持协作的模型之间的关系。
一个有趣的概念是上游（上文）还是下游（下文）的概念：将一种模式与另一种模式的政治影响相对应。但是基于这种类型的推理，我们有一些描述可能的协作类型的模式。下面是针对DDD上下文映射的一个简短摘要。
- 伙伴关系模式：两个团队相互依赖，并为实现共同的目标而合作。
- Customer-Supplier客户-供应商模式：依赖性不太对称，优先级可能会有所不同。无论如何，团队之间还是可能需要沟通的。
- Conformist遵从者模式：遵从的一方更改会最少。下游方要想得到他们所得到的。
- 反腐败层：仍有利于下游，但我们未采用外部模型。实际上，我们正在编写一个厚适配器模式，以使我们的模型与外部模型严格分开。
- Open-Host开放主机模式：利于上游，我们的模型可以在我们的条件下提供给外部用户。当然，我们需要通过文档等明确说明这些条件。
- Published Language:发布的语言模式：使用一种专门的交流通用语言可以使更大范围的对话成为可能。
- 共享内核模式：一部分在不同模型之间可能是相同的，但这意味着在修改此代码时需要有更高的关注度和质量，这里就别提依赖性了。
- 分离模式：最好的依赖关系就是我们所没有的依赖关系。有时，将事情分开是这样。
- 泥泞大球（Big Ball of Mud）：如果没有适当的边界，并且代码库成为工作的可怕之地。
在DDD中，当绘制“上下文映射”时，这种分类变得很有趣，绘制映射会迫使我在开始项目之前询问相关问题。例如，如果我的团队打算在一个不可靠的平台上，在一个业务关键项目上保持一致，那我会挥舞红旗。
从早期开始，我就喜欢使用上下文映射模式来捕获不同费用支出上不同方法的成本。一个合作伙伴需要更少的代码，但需要很多沟通带宽就成为可能，而一个反腐败层正好走向相反的方向，写更多的代码，因为没有对话是可能的。遵从者Conformist将使您只需要很少的代码和对话就可以了，但是却要降低质量。没有免费的午餐！
沟通交流带宽实际上是这里的关键因素。如果没有足够的带宽来支持它，那么协作就不会发生。
比较两种目标
最明显的区别是上下文映射目标不是团队，而是模型。另一方面，“团队拓扑”的目标建议是：针对模型的认知会不断进行优化，这与每个有界上下文中只有一个团队的概念非常吻合。这是两种不同的目标。
- 两种目标针对现在或将来的两种状态
团队拓扑为期望的状态提供了参考目标，而DDD上下文映射为评估当前状态提供了更细粒度的模式。
泥浆大球显然不是理想的状态，但这是描述您的可怕日常现实所需的词典的一部分。
我这里确实将上下文映射用于将来的状态，但主要是作为软件设计工具，而不是组织设计工具。在这里，团队拓扑似乎在用作参考模型方面具有优势。
- 选择有后果
两种目标的共同点是使结果明确。协作的成本很高，因此需要适当考虑这些成本。我去过很多地方，管理层邀请团队进行更多的沟通，同时填写积压和增加截止日期，从而使沟通变得几乎不可能。
仅有三种交互类型团队拓扑（Team Topologies）的轻量级教条主义是迫使管理层做出选择并承担后果的一种好方法。仅仅告诉人们合作和沟通并不是一种策略。
同时，快速更新我们的当前状态上下文映射仍然是检测当前协作状态中是否存在捣糨糊的好方法。
- “我们正在与A团队合作：我们每周都有会议！” →客户供应商模式？
- “他们只是对我们要求的每件事说'不'。” →不...遵从者模式。
- 断裂平面Fracture planes
团队拓扑将断裂平面讨论为将系统分解为不同流的自然方法。但是我对领域驱动设计非常感兴趣，无法爱上这个隐喻。好吧，我知道有个理想的位置，可以将系统切入松散耦合的有界上下文，并有效地划分团队之间的职责，我在书中写了整整一章，内容涉及如何从Big Picture EventStorming中提取此信息。
但是我也知道，要打破整体巨石，那绝不是要切断坚固的板岩。这更像是在有分支和节点的地方砍木头。您将尝试遵循这条路线，但是您将意识到，有些事情并不会那么容易被分开：有些东西会以错误的方式共享，但是使用起来又很大又很危险。
切断的地方可以是一个大类，一个大表或两者的组合。大混乱处在一切中心。
这就是隐喻听起来对我来说太容易了的地方。有很多方法可以解决这个问题（我在一个旧的演讲中谈到了它的实质），但是它们需要一定程度的精通。
还有需要考虑：
- 组织规模：当您的开发车间为20+或50+时，团队拓扑开始变得很有趣，而当您以独奏模式进行编码时，也会存在有界上下文。
- 业务压力和资产组合管理：如果没有积压压力的健康检查，则设计团队之间的完美和谐将惨遭失败。如果团队承受压力，协作将不会按预期方式进行，但是我仍然看到太多组织无法为多个从属团队进行计划。
最后，我保留了我最喜欢的想法：我认为，当今围绕“团队拓扑”进行讨论的最重要的结果就是关于一个理想状态是什么样的。大多数组织从未见过健康的组织（严酷但真实），因此提供参考模型绝对是一件好事。
请不要陷入"将这种理想状态就视为稳定"的陷阱，也不要一劳永逸地解决团队结构问题。每个解决方案都将是短暂的。合作是暂时的，每当上下文发生变化时都需要进行审核。但是，您肯定会拥有更好的工具来做出正确的决定。