今年早些时候，我和 DrDoctor 的几位同事参加了 C4 架构建模1 的培训。培训师讲得非常好，经过几节课的学习，我们掌握了这种方法。我们继续运用所学知识，在 3 个月的时间里，每周四与所有人员会面。我们主要侧重于将现有架构建模为 1 级（上下文）和 2 级（容器）图。这个过程很有启发性，我们都从中学到了很多东西，光是这一点就可以写好几篇文章了。
我有两个主要收获：
- 从培训本身，C4 方法提供了一种在讨论架构时可以使用的一致语言
- 在使用和应用 C4 方法的过程中，我发现图表可以促进更好的对话。
在深入探讨 C4 图表带来的好处之前，我想特别强调两个局限性。
C4 模型没有提供以书面形式传达架构故事的标准方法。考虑到 C4 模型的所有优点，如提供一致的语言、通过不同层次的图表逐步引入细节/复杂性等，我觉得这是一个疏忽，如果能有这样的功能就会非常有用。
缺乏现实世界中的可用示例--这显然不是模型本身的限制，而是由于公司不愿意公开宣传其架构的细节。不过，这确实意味着，要了解如何在公开示例之外实际应用该模型非常困难。
我们与来自 buildingbetterteams.de 的布莱恩进行了多次交流，他向我们讲解了基础知识，然后指导我们对现有架构进行建模（公司的钱花得值）。
图表能促进交流
1、培训团队新成员
您可以想象一下，当新工程师加入团队时，对话内容是这样的
- git clone /path/to/repository
- open in [your IDE of choice]
- 你为什么还没完成第一个故事/任务/票据？
上述内容中缺失的一点，也是众多缺失内容中的一点，就是上下文。
即使你的代码/解决方案遵循了 Clean/Hexagonal/DDD 布局的 "最佳实践"，你的代码仍存在会令人困惑的地方。
这些问题仍然需要提出并回答：
- 主要入口是什么？
- 项目之间的交互是什么（如果有的话）？
- 有哪些外部依赖关系？
- 是否有任何外部项目依赖于该解决方案？
这就是 C4 架构文档派上用场的地方，它们是帮助新工程师建立新项目的架构、交互和依赖关系心智模型的起点。
值得补充的是，我在团队中使用的图表不仅对新工程师有用，对我们的工程经理和技术产品经理也很有帮助，特别是帮助他们了解我们正在进行的项目的复杂性，并理解为什么某些工作比其他工作更复杂。
2、规划即将开展的工作
作为一个团队，我们最近正准备为现有系统开发一项新的主要功能。了解功能的内容非常简单。但是，有了像样的（即相当好/足够好的）架构图，我们就能知道如何实现这些功能。架构图可以作为对话的提示。
架构图为所有团队成员提供了中心内容，也为每个人提供了共同语言。
它们还帮助我们思考实现最终目标的迭代方法。能够将我们想要实现的最终目标可视化，有助于我们思考如何以渐进的方式实现目标。如果我们只是口头讨论，我认为我们不会也不可能就如何构建这一系统得出相同的结论。
3、与其他团队沟通变更
承接上一点，我们要构建的这一新功能涉及到对 DrDoctor 的整体架构进行一些改动。这意味着，我们将对其他团队拥有的一些项目的运作方式做出改变。有了架构图，我们就可以向其他领导传达变更的范围，这改变了我们的工作方式。这些图表再次成为对话的中心内容，帮助我们团队以外的其他人建立起我们所要改变内容的心智模型。
我还能够轻松地讲述我们将通过哪些迭代来实现最终状态。
总结
我仍然觉得自己在构建（或绘制）架构图的道路上还很稚嫩，但根据最近的经验，我可以看到架构图给工程团队带来的巨大价值。这些优势让我更加坚信，为创建和维护架构图所付出的时间和精力是值得的。
- 集中交流：有了图表作为对话的中心，就改变了游戏规则，重点不再是个人，而是可以推理、质疑和探究的东西，而不会让人感觉是针对个人的。
- 普遍理解：图表的可视性有助于技术人员和非技术人员理解交互点和依赖关系。它们还为所有团队成员提供了共同语言。
- 便于规划：在规划过程中，拥有图表对规划（大小功能）有极大的帮助，特别是当团队由许多新成员组成时，能够参考组件并了解某项功能的变化范围，有助于团队了解变化的复杂性。