什么是软件架构？“系统设计”是否可以用来描述我在系统中定义的某些规则或设计的明确模块？或者它只是我定义的特定类和函数？如果我们从敏捷软件开发的角度来看软件架构，我们很快就会得出结论，在实际实施之前，几乎不可能在详细级别上定义类和模块，因为需求可能会随着Sprint的进行而演变，而且变化很快，应用程序本身也在不断变化。那么，在开始正式实现软件系统之前，我们要开发的系统的可视化软件架构究竟是怎样的呢？根据RalphJohnson的说法，软件架构被定义为：“架构是非常重要的东西，不管它是什么！”这个定义一开始肯定是发人深省的，但其中有很多道理。软件架构基本上代表了软件团队做出的决策。这与文档或绘图无关，而是关于开发团队为软件设计共同做出的决定。软件开发人员、设计师、产品经理因此就特定的架构决策达成一致，例如REST或GraphQL、Python或JavaScript，开发两种服务或只编写一种。这也让软件架构师的角色有了完全不同的意义。您不会在黑暗的壁橱中用UML和BPMN设计软件架构，然后将图表交给软件团队。这个角色的目的是指出对软件架构的不同观点，并与团队一起做出软件架构的决策，而不是为团队进行架构设计。毕竟，团队最终会实施它。那么，什么是最好的软件架构？有多种软件架构风格，例如微服务或基于空间的架构。但顾名思义，它们只是可以用于决策的样式。这实际上很快就回答了什么是最好的软件架构的问题，从来没有最好的软件架构这样的东西。一个团队共同努力并为这个软件尽最大努力做出的决定是可以为整个团队和软件需求提供的最佳软件架构。这是因为所有团队资源都用于让团队中的每个人都参与决策过程，以便与可用的人员一起开发最佳架构。如果向另一个团队提出完全相同的需求，则可能会制定完全不同的架构策略。但是，这些策略可能是整个团队的最佳决策。这是所有软件开发人员可以实现他们想要开发的软件的唯一途径。尽管如此，在我的整个职业生涯中，有一种架构风格是我所熟知的，并且经受住了时间的考验。最重要的是，我几乎从未开发过不采用这种架构风格的应用程序。我们谈论的是领域驱动的六角架构，或者说是领域驱动的六角架构。这种架构风格是EricEvans的领域驱动设计、RobertC.Martin的简洁架构和简洁编码器以及AlistairCockburn的六边形架构（也称为端口和适配器）的混合体。在这里，来自知名程序员的不同概念被结合起来，以实现清晰的规则和清晰的应用程序结构，但仍然将单独的架构决策，如REST或GraphQL、Python或NodeJS留给团队。这是一张领域驱动六边形的图片，这是一个很好的例子，说明如何定义清晰的规则，但为架构决策留出足够的空间。 域驱动六边形这可以与道路交通的示例进行比较。让路上的每个人都遵循相同的规则比让少数人遵循相似的规则并让其他人都效仿要好。在道路交通中，人们做出的决定取决于每个人，但交通流的方向是明确的。好吧，事实上，我们只需要遵循我们最终制定的规则。以架构设计为例：从长远来看，整个团队对架构的“组织”将比团队中某些人对架构的“协调”具有更好的性能：这些人确实可以快速提升决策制定和发展，但团队的其他成员被忽略了。因此，从长远来看，协调的软件架构无法承受长期波动中的简单更改和较短的开发和实施时间，而“精心策划”的软件架构甚至会因为之前团队成员的高同步成本而发生变化。.获得缓慢，但持久但高效的结果，抗波动。总的来说，相互发展比相互竞争有趣得多。
