什么是软件架构？
“系统设计”可以用来描述我在系统中定义的某些规则或设计的明确的模块？还是说，它就是我定义的具体的类和函数？
如果我们从敏捷软件开发的角度来看软件架构，我们很快就会得出这样的结论：在实际实施之前，几乎不可能在详细级别上定义类和模块，因为需求可能会随着Sprint的进行而快速变化，而应用程序本身也会随着时间的推移而不断变化。
那么，在开始正式实现软件系统之前，用来具象化我们将要开发的系统的软件架构到底是什么？
根据Ralph Johnson的说法，软件架构被定义为：“架构是非常重要的东西，不管它是什么！”
这个定义一开始肯定会让人清醒下来，然而它却蕴含着许多真理。
一个软件架构基本上代表了一个软件团队所做的决定。它不是关于记录或画图，而是关于开发团队一起为软件设计做出的决定。软件开发者、设计者、产品经理因此在具体的架构决策上达成一致，如REST或GraphQL、Python或JavaScript、开发两个服务或只写一个服务。
这也使软件架构师的角色有了完全不同的意义。你不是在黑暗的柜子里用UML和BPMN设计一个软件架构，然后把图交给软件团队。这个角色的目的是指出软件架构的不同观点，并与团队一起为软件架构做出决定，而不是替团队做出架构设计。毕竟，团队最终会实施它。
那么，什么是最好的软件架构？
有几种软件架构风格，如微服务或基于空间的架构。但顾名思义，它们只是可以用于决策的风格。
这实际上很快就回答了什么是最好的软件架构的问题，从来没有最好的软件架构这一说。一个团队齐心协力、尽己所能地为这个软件考虑作出的决定，是为整个团队和软件需求所能给出的最佳软件架构。这是因为所有的团队资源都被用来让团队的每个个体都参与到决策过程中，以现有的人员开发出最好的架构。
如果完全相同的需求提供给另一个团队，可能会做出完全不同的架构策略。然而，这些策略又会是整个团队的最佳决定。这是全体软件开发人员能够实现所要开发的软件的唯一方法。
尽管如此，在我的职业生涯中，有一种架构风格是我所了解的，并且经得起时间的考验。最重要的是，我几乎没有再开发过不是这种架构风格的应用程序。
我们谈论的是领域驱动的六边形架构，或者也叫领域驱动的六边形。这种架构风格是Eric Evans的领域驱动设计、Robert C. Martin的Clean Architecture和Clean Coder以及Alistair Cockburn的六边形架构（也叫Ports and Adapters）的混合体。在这里，来自知名程序员的不同概念被结合起来，以实现清晰的规则和清晰的应用结构，但仍将个别架构的决定，如REST或GraphQL，Python或NodeJS，留给团队。
这里有一张领域驱动六边形的图片，它很好地说明了如何定义清晰的规则，但又为架构决策留下了足够的空间。
领域驱动六边形
这可以用道路交通的一个例子来作比较。让道路上的每个人都遵守同样的规则，比让少数人遵守类似的规则，然后让其他人都跟着这少部分人来做要好。在道路交通中，人们做出什么样的决定取决于每个个体，但车流的方向却是明确规定的。那么，其实我们只要遵守最终得到的规则就好了。
放到架构设计的案例中：从长远来看，整个团队对架构的“编排”比起团队中部分人对架构进行“协调”会具有更好的表现：这些人确实能够快速推动架构的决策和演进，但其余的团队成员却被忽略了。
因此，从长远来看，协调得到的软件架构在长期的波动中无法承受简单的变更和较短的开发实施时间，而“编排”的软件架构即使最初会因为团队成员之前的高同步成本而变得迟缓，但持久地却能产生高效的结果，抵御波动。总的来说，相互之间的开发比相互之间的竞争要有趣得多。
