将 DevOps 运动中的团队拓扑与领域驱动设计社区的上下文映射相结合，可以深入了解软件工程团队之间的潜在摩擦接触点。
团队拓扑是Matthew Skelton和Manuel Pais 的作品，我将它用作我工作的一部分。从社会技术的角度来看，团队优先的方法对任何组织都至关重要，有助于降低意外的复杂性。因此，我经常被问到“我们如何在 DevOps 中运作？” 或“我怎样才能拥有可靠的服务来为我的客户创造价值？”。
将 DevOps 运动中的团队拓扑与领域驱动设计社区的上下文映射相结合，可以深入了解软件工程团队之间的潜在摩擦接触点。您可以在下方找到如何将其组合以及如何产生想法以推动您的组织达到新的绩效水平，从而创造一个安全健康的工作环境。
服务可靠性品质
有不同的可靠性质量，我们有关于它的文献。想想SRE从谷歌或图书大厦进化架构从尼尔福特，丽贝卡帕森斯和帕特里克挎。它们描述了数字服务的不同质量和不同的方法。但是在将这些概念付诸行动之前，它如何影响团队？
社会技术思维付诸行动
为了回答这个问题，我在研讨会模式下使用上下文映射和团队拓扑来可视化 (1) 域、有界上下文及其交互，以及 ( 2）团队以及他们如何互动。遵循这条路径，它允许相关人员看到他们所处环境的复杂性以及团队如何组织以创建问题空间的解决方案。
拥有这些从社会和技术角度来看的见解，它使人们能够对他们的设计选择进行推理。通过设计选择，我指的是团队和个人的组织（组织设计）和技术设计（解决方案/软件架构）。因此，在社会技术思维中，团队的概念不是事后的想法。
首先我想写另一个重要的概念。复杂性Complex，即在软件领域。Frederick P. Brooks Jr.早在 1986 年就撰写了论文No Silver Bullet - Essence and Accident in Software Engineering，在那里他描述了两种类型的复杂性：基本复杂性和偶然复杂性。复杂性是分布式系统所固有的（作为一种思考练习，您可以考虑将一个 Web 服务器连接到一个数据库服务器的堆栈），我们从复杂问题构建复杂的解决方案。比我们预期的更多，解决方案有机地增长（使用Kent Beck妙语，我们不知道任何其他类型的增长），但不幸的是它几乎是偶然的；解决方案的复杂性超过了问题的复杂性。
回到服务可靠性质量：我看到人们要求服务 X具有更高的可用性（或任何其他能力）。同样，团队不断添加组件来尝试实现它，增加了更多的认知开销。意识到这一点（我很内疚，因为我过去也有同样的行为），我开始从另一个角度看待这个问题：如果答案是团队互动的方式，而不是投入更多的技术呢？
使用来自DDD上下文之间映射和团队拓扑的见解，我们可以对组织设计进行推理，以实现所需的服务可靠性质量。通常，我有几个问题，例如：
- 价值流是否跨越多个团队？如果是这样，这些团队类型是什么？平台和流对齐的混合？
- 他们属于同一个部门还是不同的部门？
- 他们有相同的经理吗？
- 团队是在同一地点，还是在不同的时区？
- 我们是否在不同的有界上下文中共享模型？
- 我们是否需要修改我们的 SLA/SLO/SLI？
- 我们应该采用实时文档吗？
- 我们有多少交付？
根据我的经验，在改变技术方面之前，查看团队如何互动以及我们如何布局我们的解决方案是发现和提高服务可靠性质量的良好开端。随着组织的发展，复杂性也会增加，因此制定设计决策以应对复杂性非常重要。
让我们想象一个例子
如您所见，我将 Team Gold 放置在图表的中间。另外，其余的团队都有与其目的相关的名称，我将让您的想象力来填充技术细节。现在，在这个虚构的案例中，金牌团队被要求缩短功能到生产的周期时间，因为他们正在失去与竞争对手的差异化功能。基于团队拓扑，我们可以看到与不同团队的不同交互模式可能会影响功能周期时间。
在本练习中，假设团队 ERP 拥有有界上下文线索信息，团队 CRM 拥有有界上下文客户信息和客户分析，而金牌团队拥有有界上下文合格线索和线索分析。通过快速分析，我们可以发现，虽然 Team Gold 和 Team ERP 之间的关系是 X-as-a-Service，但实际上，Qualified Leads 是符合 Lead Information 的。如果团队 ERP 决定对其有界上下文进行更改，那么 Team Gold 将出现级联故障。在相反的方向上，Lead Analytics 和 Lead Information 之间的关系是Customer/Supplier，其中 Team Gold 可以影响 Team ERP 所做的决策。最后但并非最不重要的是，我们有一个团队来管理文档；然而，没有一个有界上下文与之相关。
在这个简单的例子中，我们可以看到改进团队与职能需求的一致性的潜力。根据我的经验，这是发现和提高可靠性质量的第一步。如果团队的职责与有界上下文保持一致，并且团队朝着最有利的交互模式努力，则可以提高系统的可靠性。对于采用不同协作模式的组织来说，从产品层面发现边界是一个很好的起点；所涉及的团队和有界上下文是什么，以及可能/应该改变什么以实现所需的可靠性。考虑到这一点（换句话说，基本的复杂性）设计组织可以在保持团队自主性的同时促进团队之间更好的协作。
启发
可用于生成洞察力的一小部分启发式方法：
- 团队互动匹配上下文关系
- 投资于团队环境，然后投资于技术
- 通过改善团队互动来提高可靠性
作者背景：
João Rosa主要在复杂的环境中运作，高度监管，有数百个团队，战略软件交付顾问