你是一家小型初创公司的一部分。您脑子里只有一件事：运送产品并快速找到适合市场的产品。代码为王！软件架构？但是，事实证明，每个系统都有一个架构。无论它是不是好产品，特别是在产品起飞，从初创阶段转向规模扩大阶段时，你才会发现它。 Picnic团队首先在荷兰的一个城市提供杂货，然后在全国范围内提供杂货，后来扩展到德国，最近扩展到法国。我们得到了产品并找到了我们的市场。 Picnic 的系统和团队也在以相应的速度发展。大约 20 个产品团队构建和维护从最初的核心系统发展而来的服务。在过去的一年里，我们的技术团队规模增加了一倍多。尽管如此，跨这些服务的软件架构仍然是一个临时且相当隐含的问题。 从团队的角度来看，架构选择似乎是最佳的，但从整个系统来看，它们往往不是。在这篇文章中，我们将探讨如何通过赋予软件架构更突出的作用来改进这一点。这篇文章不会涉及特定的架构风格或技术：这实际上取决于您正在构建的产品。我们可以分享的是我们为提高系统架构质量而设计的流程。 虽然产品团队自主构建和交付（微）服务很棒，但在扩展时会出现一些问题。特别是围绕更大的计划，开发跨越多个产品。不止一次，关键的技术依赖是在流程后期发现的。这会导致重复工作或返工。再举一个例子，多个团队转向了更多基于事件的架构，但以不同的方式和不同的时间线。更一般地说，关于如何有效应用那些仍然局限在孤立团队中的新技术的见解。 架构工作组 在这一点上，我们认为从长远来看，完全分散的架构决策（或缺乏架构决策）会损害我们的使命。同时，钟摆也不应该完全向另一个方向摆动。在扩展环境中，完全集中所有架构决策既不可行也不可取。守门行为会减慢团队的速度并破坏自治。 因此，架构工作组 (AWG) 应运而生：由来自各个产品团队的经验丰富的工程师组成的小组，他们提供部分时间为整个技术团队解决架构问题和挑战。AWG 的目标是授权各个产品团队做出正确的决策。为此，团队需要对架构上重要的开发有一个粗略的概述，以及一个从团队收集输入并向团队提供反馈的过程。 我们决定采用轻量级流程，邀请产品团队为重大开发编写架构提案。重大意味着它要么是一个大项目，要么涉及许多团队和系统，因此会带来独特的风险和挑战。 架构提案作为 AWG 审核流程的输入。这样，架构工作组就有机会权衡即将发生的架构重大变化。通过引入此过程，可实现以下结果：
- 协调：可以预先发现产品团队之间的潜在冲突或机会，避免重复工作。
- 质量：通过对架构提案提供整体反馈，我们提高了整体架构的一致性和质量。
- 文档：重要的架构决策通过架构提案进行记录，每个人都可以使用。
- 目标/要求：描述提议变更的业务成果。如果这部分不能写清楚，就无法判断提议的架构更改的有效性。有时，提案会被搁置，直到对实际目标和要求足够明确为止。
- 当前解决方案：简要描述当前域模型的相关部分，并提供现有服务及其交互的上下文图。
- 提议的解决方案：描述变更及其架构影响，重点关注新服务、API 设计、数据建模、与现有系统的集成以及可能采用的新技术。我们提供有关何时使用组件图或序列图的指南。
- 操作问题：概述负载和性能目标，以及更改的任何安全注意事项。此外，如果提案中有 API 更改或其他需要管理的依赖项，则团队应提供推出计划。
- 风险：架构总是要权衡取舍。在架构设计阶段识别出的任何风险，以及影响评估和缓解策略都应记录在案。