这是来自martinfowler.com的Andrew Harmel-Law文章，大意如下，详情点击标题：
架构设计不必是独白；不是从少数人的思想和口中自上而下地传递的。这篇文章描述了另一种构建架构的方法；作为一系列对话，由分散和授权的决策技术驱动，并由四个学习和对齐机制支持：决策记录、咨询论坛、Team-sourced原则和技术雷达。
软件架构的“传统”方法（即非编码、决策、图表绘制）对我来说很难发挥最好的作用。
有没有替代方案？
在本文中，我将介绍这种替代思维方式以及相关的工具和实践集，它们使我能够颠覆“软件架构师”的传统角色，同时将软件架构实践带到开发团队的前沿。更重要的是，我将解释如何在这种替代方法中，每个人都可以安全有效地进行他们需要的架构，而不会让一切陷入混乱。
软件交付朝着不断增加的团队自治的方向发展，这加剧了对更多架构思维与架构决策的替代方法相结合的需求。
一个关键问题：一小群架构师如何养活大量饥饿的、价值流对齐的团队？我们需要的是一种可行的方法来应对团队自治和由此产生的架构的人类规模挑战。
通过“咨询流程”做出决策
传统的、自上而下的架构，由精选的全能架构师做出所有决策，与这种分散的模型背道而驰。“然而”，挑战是“仍然需要做出决策——这就是架构”。
这些架构决策仍然必须经过深思熟虑。
建议流程是这种无政府主义的、分散的架构方法的核心要素。它最大的特点是非常简单。它包含一个规则和一个限定符：
规则：任何人都可以做出架构决策。
限定符：在做出决定之前，决策者必须咨询两个群体：第一个是将受到决定有意义影响的每个人。第二个是在正在做出决定的领域具有专业知识的人。
这就是整个咨询流程。
...
对话的基本作用
事件风暴的发明者阿尔贝托·布兰多里尼 (Alberto Brandolini) 曾说过一句著名的话，“是开发人员有了自己的假设（根据）他们才能投入生产”，他是对的；重要的是开发人员对目标架构的理解，而不是首席架构师的头脑或图表中的内容。
这个问题由来已久。Eric Evans 在“领域驱动设计：解决软件核心的复杂性”中解决了这个问题，最近我的同事 Erik Dörnenberg 在他的演讲“没有架构师的架构”中谈到了它。
对我来说，最重要的是这种架构，在那些编写代码的人的头脑中。在采用这种分散的方法时，架构决策的实践更加分散，这个问题在很多方面都得到了缓解。
采用咨询流程为任何人提供了决策空间，但它也将对话、寻求专业知识的责任和考虑影响置于核心位置。这种方法的其余要素，每个要素都支持核心要素，重点是确保这些对话尽可能及时、集中和有效。其中有四种：
- 一个思考和记录的工具：第一个支持元素是架构决策记录或 ADR。这些是轻量级文档，经常与它们描述的人工制品一起存储在源代码存储库中。
- 谈话的时间和地点；
- 照亮和引导统一方向的灯；
- 一种感知当前技术格局和气候的手段。