模块化架构如何与开发团队对齐，提升软件交付效率

模块化架构能提升软件交付效率吗？答案是肯定的，但前提是不能只把它当作一项单纯的技术改造。

本文讲述了一家大型企业如何通过向模块化架构转型，缓解移动应用开发在业务增长过程中暴露出的多重问题。他们最终发现，模块化并不只是架构层面的解决方案。它的影响远远超出代码结构本身，还会延伸到业务沟通、团队组织方式以及开发者体验等方面。只有同时关注这些因素，模块化架构才能真正释放价值。通过这种系统性改造，该企业显著提升了移动应用的交付表现。

本文将说明移动应用扩展问题、技术架构与团队结构之间的直接关系。在过往与大型企业合作的实践中，我们发现，不同组织在扩展移动业务时会遇到各不相同的问题和诉求。但在大型企业的移动应用开发中，以下两个问题尤为常见：

1. 面向不同市场的应用推出新功能所需时间越来越长；
2. 由于内部各市场应用之间缺乏兼容性与复用能力，导致功能差异不断扩大。

本文记录了某客户在解决这些问题时经历的模块化架构转型过程。这个案例表明：很多时候，组织选择的方案本身并非错误，问题在于它们没有理解这些方案之间的内在联系。因此，即使采用了看似正确的做法，也未能获得预期收益。

在这个案例中，该组织通过让团队拓扑与模块化架构相匹配，并持续投资开发者体验，最终实现了平均交付周期缩短 60%、开发成本降低 18 倍、团队启动成本降低 80%。

识别移动应用交付效率下降的信号

即便出发点良好，软件质量和交付表现也常常会随着时间推移而下降。功能发布时间变长，服务中断更严重，恢复时间更久，这些都会让产品和开发团队感到挫败。

其中一部分原因确实来自代码本身及其维护方式。然而，如果把问题完全归咎于代码质量，就过于简单化了。实际上，这是一个多因素共同作用的结果。随着时间推移，产品决策、组织沟通结构、技术债务以及僵化的架构会相互影响，最终导致交付效率下降。

本文讨论的这家公司是一家规模较大的零售企业。它的移动应用在推出新功能时，所需时间正在逐渐拉长。

起初，该组织正确地意识到，问题来自应用规模扩大后复杂度不断上升：现有开发团队越来越难在保持已有功能一致性的同时，继续快速添加新功能。于是，他们最初的应对方式是“增加开发人员”。在一定阶段，这确实起到了一些作用。

但很快，他们发现增加人手也带来了新的问题：沟通压力显著上升，技术负责人开始承担越来越重的协调负担。海外某些互联网公司曾提出“两张披萨团队”原则，即一个团队的规模应该小到两张披萨就能喂饱。其背后的逻辑是：限制团队规模，可以避免团队把过多时间花在沟通协调上，而不是实际创造价值上。

这个理念本身很有道理，也在一些企业中取得过成效。然而，当组织面对一个已经过于庞大的既有团队时，往往会机械地照搬这种做法，试图通过拆分团队来减轻负担。但如果只拆团队，而不调整系统边界、责任边界和协作方式，问题反而可能更加严重。

通过限制认知负荷提升团队效率

这家公司也遇到了类似情况。它曾经规模较小，业务也持续增长；但随着功能、职责和团队成员数量不断增加，组织逐渐无法维持过去的交付速度。

面对迫近的功能交付期限，以及即将进入的多个品牌市场，他们采取的措施是：将原有团队拆分为多个规模更小、彼此相关的子团队。每个团队独立运作，分别负责一个市场，尽管这些市场中的客户旅程非常相似。

但事实证明，这种做法让情况变得更糟。团队拆分只是把沟通负担从技术领导层转移到了实际交付团队身上，却没有真正降低团队需要理解和处理的上下文复杂度。

当我们意识到沟通与协调正在占用价值创造者越来越多的时间时，最初的建议是采用“限制认知负荷”的思路。也就是说，团队应该围绕各自能够承担的复杂领域进行组织，而不是让每个团队都面对整个系统的复杂度。

软件内部的领域边界，可以用来组织前面提到的小规模团队。这样一来，每个团队的工作负担会明显降低：团队目标更清晰，使命感更强，沟通和上下文切换也能围绕共同目标得到简化。

从理论上看，这似乎是解决问题的理想方案。但如果孤立地看待它，也可能产生误导。只有当应用的领域边界被清晰定义，并且在代码中始终得到遵守时，限制认知负荷的优势才能真正发挥出来。

领域驱动设计与限界上下文治理

领域驱动设计（Domain-Driven Design，DDD）有助于将复杂业务逻辑划分为更易管理的部分，并为每个部分定义统一语言和模型。然而，将应用拆分成多个领域，只是持续治理过程的一部分。

严格管理限界上下文，与定义领域本身同样重要。

在检查客户应用代码时，我们发现了一个常见问题：组织最初投入了大量精力来正确定义和组织领域职责，但随着应用持续增长，这种规范逐渐被削弱。来自业务和技术相关方的反馈表明，为了满足紧急产品需求，团队不断走捷径已经成为常态。

这反过来导致技术债务持续累积，并进一步拖慢价值交付速度。随着代码发布变得更加困难、问题调试成本不断增加，应用的关键交付指标也呈现出明显下降趋势。

通过常用代码分析工具，我们发现了更多限界上下文管理不善的信号。代码库已经变得高度耦合且缺乏内聚性。高度耦合的代码很难在不影响系统其他部分的情况下修改；低内聚性的代码则承担了许多与自身职责不一致的关注点，使人难以理解其真正用途。

随着客户应用中每个领域的复杂度不断提升，这两个问题也随时间进一步加剧。

另一些信号则与认知负荷有关。应用中各领域之间边界不清，或依赖关系混乱，意味着对某个领域的修改很可能无意中影响其他领域。我们注意到，正因如此，开发团队必须掌握多个领域的知识，才能解决任何可能出现的问题。这显著增加了他们的认知负荷。

对该组织而言，严格控制每个限界上下文，是确保知识与责任归属一致的重要一步。这既限制了任何变更的“影响半径”，也限制了完成变更所需的工作量和知识范围。此外，加强对技术债务累积与偿还的控制，也有助于确保任何短期的“领域边界侵蚀”在扩大之前被识别、拒绝或纠正。

该组织的移动应用还缺少另一项重要能力：选择性复用。

如前所述，当时企业内部已经存在多个成熟的品牌市场应用。这些应用之间功能一致性较低；同时，由于各市场都希望保持一定独立性，也很难将它们整合为一个统一移动应用。

系统内部的紧密耦合降低了现有功能在其他市场中复用的能力。仅仅为了在另一个市场复用某个领域功能，就必须迁移现有移动应用的大量内容，这带来了高昂的集成成本和持续维护成本。

通过适当管理领域限界上下文，组织减少了对其他领域的直接依赖，迈出了实现模块化的第一步。但很快我们发现，这还远远不够。

超越单个应用的模块化领域

场景一：边界清晰的单体

以单个应用中的功能请求为例：功能请求会交给负责相关领域的应用团队。由于限界上下文受到严格保护，变更的影响范围会被限制在该领域内部。也就是说，功能可以独立构建、测试，甚至部署，而无需修改应用的其他部分。

这会加快产品上市速度，并允许多个功能在隔离环境中并行开发。看起来非常理想。

确实，在单一市场环境下，这种方法效果很好。然而，当我们试图解决第二个扩展问题，也就是由于缺乏复用能力而导致的市场功能差异时，问题就开始出现了。

场景二：下一个市场机会

该组织推进领域模块化的下一步，是将“边界清晰的单体”中的部分功能迁移到其他现有市场应用中，从而快速节省开发成本。

这需要创建一个通用框架。这个框架允许功能或领域在原始应用之外，被其他移动应用复用。

为了更清楚地说明这一做法，我们以两个市场应用为例：一个服务于英国市场，另一个是服务于美国市场的新应用。美国应用团队决定，除了美国市场特有的领域之外，还希望在自己的应用中使用“积分”和“结账”这两个领域，于是他们将这些领域导入自己的应用。

对公司而言，这似乎意味着：与过去在不同市场重复开发同类领域功能相比，市场团队的开发成本可以降低一个数量级。

但故事并没有就此结束。在急于推动模块化的过程中，组织忽略了既有沟通结构，而这些结构最终决定了工作的优先级。

继续前面的例子：美国团队在自己的市场中使用这些领域后，希望为其中一个导入领域添加新功能。由于他们并不拥有该领域，也不了解其完整上下文，于是他们联系英国应用团队并提交了功能请求。英国团队接受了这个请求，也认为它“听起来不错”，但他们目前正在处理英国市场相关方提出的需求，因此无法明确什么时候才能开始这项工作。

我们发现，领域功能优先级上的利益冲突，限制了共享功能消费者能够获得的复用价值。当市场团队因为导入领域迟迟没有进展而感到沮丧时，这一点尤其明显。

我们曾提出过一些解决方案。例如，消费者团队也许可以创建自己的领域版本，并围绕该版本组建团队。但正如我们所知，为了添加少量功能而学习并拥有整个领域，是低效的。而且分支版本会给未来升级、共享以及跨市场功能一致性带来问题。

另一个方案是通过拉取请求进行贡献。然而，这会给贡献团队带来额外认知负担：他们被迫在第二个代码库中工作，同时仍然依赖主领域团队提供跨团队贡献支持。例如，我们无法确定领域团队是否有足够时间，在完成自身市场功能开发之外，再提供架构指导或代码审查。

场景三：与市场无关的领域

显然，问题出在团队组织方式上。

康威定律指出，组织会设计出与自身沟通结构相匹配的系统。前面的例子描述了这样一种情况：从技术角度看，功能已经模块化；但从所有权角度看，它仍然是单体式的——“积分系统最初是为英国应用开发的，所以它属于英国团队”。

针对这种情况，一种可能的应对方式是采用“反向康威策略”。该策略强调主动改变开发团队结构，使其能够促成期望中的技术架构。

在后续实践中，我们基于前面的场景调整了团队结构，使其与模块化架构保持一致。各个领域不再隶属于某个特定移动应用，而是成为由独立开发团队负责的产品能力。

调整之后，应用团队之间的关系发生了变化：他们不再依赖其他市场团队来提供功能。取而代之的，是一种更适合用“消费者”和“提供者”描述的新关系。

领域团队向市场应用提供功能；市场应用使用这些功能，并反馈新的功能需求，从而推动领域产品持续演进。

这次重组相较之前最大的优势，是明确了关注点。此前我们曾描述过，当一个市场要求修改另一个市场所拥有的领域时，就会出现利益冲突。将领域从其所属市场中分离出来后，团队关注点也随之变化：不再只是为了某个市场的局部利益构建功能，而是更全面地构建能够满足领域用户需求的能力。

成功的衡量标准也随之变化。它不仅包括市场采用情况，还包括最终用户反馈。任何新功能的评估，都应基于它能否为领域及其用户整体带来价值。

关注开发者体验，支撑模块化架构落地

至此，该组织已经拥有了一种支持跨市场组件模块化的团队拓扑。各个自主团队被分配到相应领域，并负责这些领域的持续开发。市场应用则被简化为配置容器。

从概念上看，这一切都说得通。我们可以轻松画出反馈如何从消费者流向提供者的流程图，也可以提出一些高层次的理想假设，例如：“所有领域都可以独立开发和部署”，或者“消费者只需要引入任何想要复用的领域，就能构建自己的应用”。

然而在实践中，我们发现这些都是难以解决的技术问题。

例如，如何在多个独立领域团队之间保持用户体验和品牌一致性？当你只负责整个应用的一部分时，如何进行移动应用开发？如何确保领域易于发现、易于测试，并且能够跨市场兼容？

这些问题并非无法解决，但它们会带来沉重的认知负担。而在当时的组织结构中，并没有明确的负责人。因此，我们设立了新的负责人。

用平台领域解决模块化架构的核心问题

我们将新的领域归类为“平台”。

“平台”本质上是一个覆盖范围很广的概念。我们用它来描述那些能够帮助团队在既定架构下独立交付的工具、能力和指导。新的平台领域团队延续了前面建立的提供者 / 消费者关系，并负责提升团队在平台内构建应用和领域时的开发者体验。

在这类转型中，研发过程的可视化和数据流转同样关键。企业通常需要一套贯穿目标、反馈、需求、计划、开发、测试、发布与知识沉淀的研发管理体系，例如 PingCode 这类智能化研发管理工具，就可以帮助团队把模块化架构下的需求流转、项目协作、测试发布和经验沉淀串联起来，让研发管理更加自动化、数据化和智能化。

我们的假设是：更好的开发者体验，将有助于推动新架构被更广泛地采用。

但“开发者体验”（Developer Experience，DX）是一个相当宽泛的概念。因此，我们认为有必要明确：新团队需要具备哪些能力，才能真正提供良好的开发者体验。

我们将开发者体验细化为一系列必要能力。首要能力，是高效的启动流程。

任何通用框架都不可避免地存在学习曲线。良好的开发者体验，目标就是尽可能降低这条学习曲线的陡峭程度。合理的默认设置和入门套件，是一种非强制性的方式，可以减少用户上手时的阻力。

以下是我们为平台领域定义的一些承诺：

• 你只需一条命令，就可以快速生成一个新的领域，其中包含所有相关移动依赖、通用 UI/UX、遥测能力和 CI/CD 基础设施。
• 你可以独立构建、测试并运行自己的领域。
• 你的领域被打包进应用运行时，应当与独立运行时保持一致。

请注意，这些承诺描述的是开发者生产力平台中的自助服务体验。因此，我们认为，一个高效的开发者平台应该让专注于最终用户功能的团队聚焦于自身使命，而不是被看似无穷无尽的低效流程消耗。

我们为平台领域确定的第二项必要能力，是“技术架构即服务”。

在组织内部，架构职能同样会受到康威定律的影响，导致架构决策责任集中在一个独立部门中，并与真正需要指导的团队脱节。我们的自主团队虽然能够做出自己的决策，但往往仍然需要一定程度的技术指导，以便在原则、模式和组织治理方面保持一致。

当我们把这些需求扩展为按需服务时，就形成了如下模式：

• 我们提供的最佳实践，会附带可直接使用的示例，或可执行的实际步骤。
• 我们会持续掌握每个应用对领域的使用情况，并在需要时协调跨领域协作。
• 通往生产环境的路径应当清晰、可见且正确。
• 我们会与你们共同协作。

请注意，这些承诺体现的是一种服务型领导与团队之间的关系。它承认每个人都对架构负有责任。这与一些组织中常见的命令与控制式架构治理策略截然不同。

关于平台领域，还有最后一点值得回顾，而且它与前面的例子密切相关。

根据我们的经验，一个成功的平台团队必须深入理解客户需求。在海外某些制造企业的精益实践中，有一个理念大致可以理解为“亲临现场、亲自观察”。它强调：只有亲自到问题发生的地方，才能真正理解问题并找到解决方案。

我们认识到，一个致力于提升开发者体验的团队，必须能够设身处地理解使用其产品的开发者，才能真正理解他们的需求。

最初组建平台团队时，我们并没有给予这一原则足够重视，结果导致各独立团队各自为政。最终出现了重复建设、系统不兼容以及对架构缺乏信任等问题，而这些问题都需要花费时间来纠正。

模块化架构转型带来的结果

我们已经讲述了如何对移动应用进行模块化改造。那么，随着时间推移，这种改造效果如何？

获取实证数据并不容易。根据我们的经验，在同一组织内同时拥有一个旧版应用和一个采用新架构的应用，并且这两个应用使用相同领域、各自又具备独立交付指标，这种情况并不常见。

不过幸运的是，在这个案例中，该组织规模足够大，可以一次只改造一个应用。

为了得出这些结果，我们比较了两个功能相似的零售应用。一个是高耦合、低内聚的旧版应用，尽管它的开发团队高效且成熟，我们称之为“旧版单体应用”。另一个应用则是前文描述的模块化重构实践成果：它拥有定义清晰、管理有序的限界上下文，并由较新的独立领域团队支持，我们称之为“限界上下文应用”。

这里，交付周期是一个很好的衡量指标，因为它代表代码变更所需的时间，并且不包括将应用推送到应用商店所需的时间。后者是一个时长可变的过程，与应用架构类型无关。

移动应用类型	交付周期
旧版单体应用	17 天
限界上下文应用（平均值）	10.3 天

即使对第二个应用中所有领域团队的交付周期取平均值，也可以看到：与由更成熟团队开发的旧版应用相比，新架构下的交付周期仍然显著缩短。

第二个比较关注的是选择性复用能力，或者更准确地说，是缺乏这种能力所带来的成本。

在这个场景中，我们考察了组织内的两款移动应用。其中一款应用需要现有领域功能，但没有复用选择，只能自行开发；另一款应用则采用模块化设计，能够即插即用已有领域功能。

我们忽略了上线流程中的常规步骤，因为它们不会影响这里的衡量指标。相反，我们专注于开发团队可控的部分，并衡量由一对开发人员与一名全职设计师合作完成的开发流程：从预生产阶段的“产品验收”到最终开发完成。

集成类型	平均开发时间
非模块化	90 天
模块化	5 天

以上差异显著的数据表明：在存在明确业务需求的场景中，模块化架构具有强大的价值。

顺便说一句，我们排除在外的外部因素同样值得关注。优化开发绩效往往会暴露整体流程中的其他瓶颈。例如，如果发布一个版本需要 6 个月，而审批流程需要 1 个月，那么审批在整个流程中的占比相对较小。但如果开发周期可以缩短到 5 天，而审批仍然需要 1 个月，那么合规审批就可能成为下一个需要优化的瓶颈。

上述结果没有体现的另一项优势，是围绕特定领域组建的团队对集成活动产生的影响。我们发现，自主领域团队会自然而然地将自己的成员嵌入市场应用团队，以加快集成进程。

我们认为，这源于领域团队关注点的转变：领域产品的成功取决于它被市场采用的程度。

我们发现，影响采用率的因素可以理解为两个同心反馈回路。

外层回路是领域消费者，也就是应用容器的良好集成体验。这是一个以开发者为中心的反馈回路，衡量标准是消费者能否轻松地将某个领域配置并集成到整体品牌产品中。

内层回路是良好的最终用户体验，即消费者所服务的市场客户是否接受完整流程，其中包括被集成进来的领域。

糟糕的消费者体验会影响采用率，并最终可能导致领域团队与真实用户脱节。我们发现，那些与消费者团队紧密合作，并且能够直接接触最终用户的领域团队，拥有最快的反馈循环，因此也最容易取得成功。

最后，还值得提到平台领域带来的一个对比。

开发一项新的领域功能非常耗时，也会增加整体功能开发成本。正如前文所述，平台团队的目标，是通过识别并优化流程中的痛点来缩短开发时间，从而提升开发者体验。

当我们把这一模型应用到模块化架构中的领域团队时，发现每个团队的启动成本降低了 80% 以上。原本预计需要一周才能完成的工作，两个人只用一个下午就能完成。

模块化架构的局限性

现在，你应该已经比较清楚地看到了移动端模块化架构的优势。但在对摇摇欲坠的单体应用进行大规模改造之前，务必记住这些方法的局限性。

首先，也是最重要的一点：这种架构转型需要长期投入大量时间和精力。它只应当用于解决与产品上市速度相关的重大业务问题。

其次，赋予领域团队自主权既可能带来好处，也可能带来挑战。平台团队可以提供合理默认设置作为通用实现，但最终选择权仍然在各个团队手中。

当然，如果领域团队希望自己的能力被市场接受，那么在平台要求方面达成共识，例如统一 UI/UX，对他们而言是有利的。然而，要管理来自相似内部依赖或多种设计模式所造成的系统膨胀，并不容易。

如果忽视这个问题，任由整个应用不受控制地增长，最终会导致糟糕的用户体验。我们再次发现，对技术领导力的投入，加上强有力的护栏和指导原则，可以通过架构与设计监督、指导，以及最重要的沟通，来缓解这一问题。

总结：模块化架构需要与团队结构共同演进

综上所述，本文开头指出了采用多应用策略的组织中常见的两个重大交付问题：新功能上线时间不断延长，以及内部相似应用之间的功能差异持续扩大。

我们论证了，解决这些问题的关键，并不在于围绕技术架构、团队结构或技术债务制定某一个单一策略，而在于让这些方面协同演进，形成一套综合策略。

首先，我们展示了如何通过演进团队结构来支持所需的模块化与领域中心架构，从而降低认知负荷和上下文负担，同时赋予团队独立开发的自主权。

接着，我们展示了如何自然地将团队和领域提升到与原始应用或市场无关的层面，以及这一转变如何缓解应用单体架构中固有的康威定律影响。我们还观察到，这种转变会自然形成消费者 / 提供者关系。

最后一个同步转变，是识别并投资“平台”领域，用以解决团队与领域解耦后产生的核心问题。

综合以上因素，我们成功将市场应用中所有模块化领域的平均交付周期缩短了 60%。此外，与从零开始编写相比，将模块化领域集成到市场应用中使开发成本降低了 18 倍。更重要的是，由于新领域启动成本降低了 80%，并且有平台团队持续提供支持，我们对工程效率的投资让模块化架构真正得以发挥作用。

对这位客户而言，这些节省意味着他们能够抓住过去因投资回报率过低而被认为不值得投入的市场机会。而在过去多年里，这些机会一直被竞争对手占据。

关键在于：在合适条件下，与团队结构紧密匹配的模块化架构，能够为组织带来巨大收益。

虽然该组织在合作期间取得了显著成果，但这些成果仍然属于具体案例。在采取行动之前，务必花时间理解自身所处的环境，寻找相关信号和反模式。

此外，切勿低估构建这类生态系统所需的前期投入和持续努力。草率行动很可能会制造更多问题。

但是，只要你接受自身情况的独特性，抵制“照搬照抄”的诱惑，并持续关注同理心、自主性以及能够支撑架构的沟通渠道，那么你完全有理由复制这个案例中的成功经验。