软件架构与建筑架构虽常作对比，但二者存在显著差异。
建筑行业在规划其结构时，会有未来三年的详尽蓝图。项目被细分为三个阶段，每个阶段都有精确的测量数据和建设规划。他们遵循严格的时间表。即便对于非土木工程背景的我来说，也能轻易理解其内容。
软件工程并非如此一目了然。虽然绘制软件架构图看似简单（使用方框和箭头），但阅读和理解它们却可能并不直接。
在我的工程师职业生涯中，我接触过大量的软件架构图和设计文档，也参与过许多系统设计的面试。我逐渐意识到，人们对软件的描述方式存在巨大差异。这种差异主要体现在以下几个方面。
- 不同层次的抽象
- 不同的细节程度
- 不同的插图/图表绘制技术
- 对非功能性方面如可靠性、安全性、隐私性和规模的不同关注
即使在同一个团队内也常见此类沟通差距，更何况不同团队、或公司之间。
例如，不完善的架构图要么使用大量的冗余文字（想象一下10页的设计文档），要么需要花费大量时间来解释其内容。
这些沟通差距可能会对项目产生重大影响。
过去，大多数公司和采用自上而下的软件设计和架构方法，为每个大规模团队雇用一名架构师，作为产品/系统设计的权威。工程师根据给定的架构、规范和API执行编码任务是常见的情况。
如今，世界正转向更加去中心化的方法。现在，各级工程师都参与到设计和架构中，而不仅仅是编写代码。
这种方法的转变体现在工程师的工作范围上——初级工程师可以设计特定组件，而高级工程师可以设计系统，甚至多系统环境。这实质上是文化和思维模式的转变，从集中式设计过程转变为去中心化且“人人参与”的过程。
这种变化带来了诸多好处：增强了各级工程师的能力和成长，提升了他们的主人翁意识和参与度，消除了单点故障，并在团队间更好地传播了知识。
这种转变也伴随着代价。例如，没有对经验丰富的架构师的需求来保证高标准的构建和维护软件系统。当为了维持高标准而推动团队采用培训、教育和指导等措施时，就要求团队建立起良好的设计流程和开放的反馈文化。
在中实施健康的设计流程是一项挑战。在引入的间接费用与实现的质量提升之间存在权衡。如果流程过于简单或根本不存在，则质量可能无法提升；而如果流程过于复杂，可能会成为工程师的负担，他们可能不会完全遵守或寻找规避方法——最终导致效率降低。
C4模型是解决上述问题的一个实际概念。它旨在将临时的、自由式的绘图技术转变为持久的、规范的和标准化的建模技术。该模型由四层抽象组成：容器、组件、限制和上下文。它为软件架构图提供了深度和协作性。
C4模型的关键在于容器和组件层。明确这些层的本质对于可扩展性、可靠性、部署和可演化性至关重要。C4模型为软件设计提供了深度和协作性。它鼓励团队使用工具和技术来创建详细的架构图，并随着产品和的发展而扩展。
在软件设计中，工具如生成式人工智能将如何影响软件开发和设计是另一个有趣的问题。我们已经看到人工智能工具、代码辅助和智能体的使用在日常工作中的变化。
你们的设计过程是怎样的？你感觉它的结构是否强大且具有影响力？或者你认为还有改进的空间吗？欢迎在下方评论中分享你的想法。