过去，大多数公司和组织都采用自上而下的方式进行软件设计和架构--为每一个足够大的团队聘用一名架构师，作为产品/系统设计的集中权威。
现在，世界已转向更加分散的方法，各级工程师都参与设计和架构，而不仅仅是编码。 不同级别和技能的工程师的工作范围有所不同，例如，初级工程师可以设计一个特定的组件，而更高级的工程师可以设计一个系统或多系统环境。
基本上，这是一种文化和思维方式的转变，从自上而下、集中式的设计流程转变为自下而上、分散式和 "人人拥有 "的流程。
代价
这种变革有很多好处：增强各级工程师的能力并使其不断成长；增强主人翁意识和参与感；消除单点故障；在团队中更好地传播知识。
但是，它也有代价：
- 质量：架构师通常是经验丰富的工程师，具有构建和维护软件系统的经验。 将这项工作分摊给团队中的每个人，意味着除了成为团队的一员外，没有其他资格要求。 为了保持较高的质量标准，团队需要在培训、教育和指导方面进行投资，建立良好的设计流程，并融入开放的反馈文化。
- 开销：在组织中建立稳固的设计流程有助于提高质量标准，但也会带来巨大的开销。 通常，此类流程涉及创建设计文档、系统图、流程图，还包括一个反馈流程，可能需要对设计进行多次迭代和传递。
在企业中实施健康的设计流程具有挑战性。 它所带来的开销与流程所实现的质量收益之间存在着矛盾。 如果流程太轻，或者根本不存在，就不会有质量收益。 如果流程过于繁琐，则会成为工程师的负担，他们可能无法完全遵守，甚至可能想方设法规避，最终导致效率降低。 最佳点始终介于两者之间。
实用心得： C4 模型
关于一个健康的设计过程应该是怎样的，有很多值得讨论的地方，但我想指出的一个实用概念是 C4 模型。 可视化是软件设计的关键部分。 如上所述，人们对软件的描述各不相同，尤其是在软件图表方面。
图表 → 建模 C4 模型旨在将短暂的、自由式的图表绘制技术演化为长期的、规范的和标准化的建模技术。 您可以将其视为一套关于如何可视化和描述软件架构的规则和惯例（类似于其他工程领域的标准）。
C4 模型由 4 个抽象层组成（因此得名）：
- 系统上下文：最高层次的抽象，包含内部系统、外部系统、用户（若有多种类型的用户，需注明）以及三者之间的关系。
- 容器：一旦您的系统到位，您就可以深入研究特定系统。系统由一个或多个容器组成。容器代表应用程序或数据存储，例如：后端服务、前端应用程序、移动应用程序、关系数据库、键值存储、消息总线、对象存储等。至少从后端的角度来看，一个简单的思考方式是考虑单独的进程/可执行文件。每个可执行 文件都映射到其自己的容器。如果您以前参加过系统设计面试，它通常会侧重于容器层。
- 组件：接下来，容器可以分解为多个组件，通常按功能和职责范围进行划分。例如，如果我们采用后端支付服务，它可能包括以下组件：支付执行器、第三方客户端、恢复机制、支付记录器、通知发送器等。容器的组件可以与第 2 层的其他容器交互 - 例如，恢复机制可以向消息总线提交消息，以在一定延迟内重试失败的支付。
- 代码：这是组件到实际代码类/模块/等的映射。这一层实现细节通常不太有趣，而且很难维护，一般不推荐用于大多数用例。然而，在编写代码时，思考“我的代码适合哪个组件？ ”
关于 C4 模型的一些注释：
- 容器层和组件层是关键层。明确这些层的本质——容器层上的设计选择会影响可扩展性、可靠性、部署和可演化性。组件层上的设计选择会影响开发人员的速度、效率、可维护性和质量。
- C4 模型为软件架构图增加了深度。可以将其视为在线地图 - 您从高级视图开始，然后可以放大到感兴趣的地方。如果您对细节太过着迷，您可以再次缩小并找到总体架构。
- C4 模型是一种协作的长期模型。C4 模型无需每个工程师创建自己的临时图表，而可以由多个工程师或团队共享和使用，并随着组织和产品的发展而扩展。
- 支持C4模型的工具有很多，现在就连常见的企业图表软件都带有C4模板。
结论
软件设计是软件开发生命周期中至关重要的环节，对产品或系统的最终结果、执行速度、可维护性和可进化性有重大影响。
随着近年来架构师角色分散和“架构作为一项团队运动”的趋势，软件团队的结构正在发生变化，组织需要仔细考虑他们的设计流程应该是什么样子，并在引入开销和维持高质量标准之间找到适当的平衡。