你不必是工程师才能成为赛车手，但你必须具备机械共鸣。
-Jackie Stewart，赛车手
"机械共鸣"一词最初由Jackie Stewart创造，用来描述赛车手的一种特质，他们需要对赛车的工作原理有深刻而直观的理解，才能发挥出车辆的最佳性能。
Martin Thompson在讨论他的LMAX架构时将这个术语应用到软件开发中，该架构利用对云系统功能的底层和直观理解来最大化其性能。Thompson多年来一直维护一个博客讨论这个话题，非常值得回顾阅读那里的文章。
在这篇短文中，我想提出另一个概念和设计原则，即架构共鸣：
架构共鸣是指一个软件采用并符合另一个软件的架构设计的特性
这是我在设计htmx和hyperscript时一直牢记的设计原则，我想把它写下来供参考，也让其他人可以思考、批评和改进它。
htmx在架构上与Web产生共鸣，因为它采用了Web底层REST-ful架构：以REST方式与超媒体服务器交换超媒体。在尽可能实际的情况下，htmx从现有的Web基础设施中获取设计线索：
htmx试图融入Web现有的概念架构，而不是取代它。
这与构建Web应用程序的SPA方法形成对比。大多数SPA框架与Web的原始模型几乎没有架构共鸣。相反，它们基本上取代了Web原始的、REST-ful的、面向超媒体的架构，转而采用更像厚客户端的架构，通过RPC式的固定数据格式网络架构交换信息。
如果一个新软件与原始软件保持架构共鸣，将获得以下优势：
当然，与任何设计原则一样，使用架构共鸣也有权衡：
我喜欢指出的一个非软件架构共鸣的例子是中世纪的大教堂：这些大教堂通常是由许多不同的建造者和建筑师（如他们所称）经过几个世纪建造、重建和改进的。然而，经过这些世纪，他们能够与早期工作者保持高度的架构共鸣。
工人们没有专注于全新的建筑方法，而是专注于保持一个连贯的整体，并在该框架内专注于他们个人贡献的工艺。是的，沿途有一些装饰和变化，但这些通常不会为了创新而牺牲整体的概念连贯性。
在软件开发中采用架构共鸣思维通常意味着牺牲你希望做事的方式，转而采用原始软件做事的方式。虽然这种约束有时可能会令人不快，但它也可以产生精心制作的软件，这些软件和谐且与现有软件很好地契合。