Answers:
完全相反的情况也是如此。
这是十大软件体系结构错误的链接。
一切都是可配置的。当架构师告诉您他的系统由于广泛的可配置性而具有防更改性或高度可定制性时，这就是体系结构的味道。
问题在于，您实际上只能为您认为现在需要配置的内容提供配置机制，但是一旦您的应用程序开始运行，这将是不够的。然后，配置机制不断扩展，最终您将获得内部平台效应。
然后您陷入软件地狱。
由ORM设计的数据库！或者是非关系数据库后端，应该是关系数据库。或您打算使用视图调用视图的视图的数据库，不仅它们太慢（必须从一开始就为性能而设计数据库），而且当您需要进行更改时，它们很难追踪（@AmirResaei说过抽象，当您需要修复所有这些层底部的内容时，很容易在代码中迷失方向。）
代码气味和建筑气味是相同的。由于架构欠佳，代码开始“闻”。
在Martin Fowler的主题为Refactoring的开创性著作中，他介绍了一系列Code Smells，并确定了将它们重构到系统之外的方法。Joshua Kerievsky的“ 模式重构”通过提供特定的架构模式来修复各种代码异味（以及如何逐步重构它们），进一步强调了这一思想。
大多数重构都是通过增强的体系结构来减轻次优代码的。有人可能会争辩说，唯一自然产生的“建筑气味”（除了“泥浆大球”之外）将是BDUF（前大设计）架构。在编写第一行代码之前，尝试容纳所有需要的内容。一个按需完成设计的敏捷软件项目（即使我敢说代码也被视为design），它的体系结构也会有机地增长。
（很多）耦合（无论以哪种形式）是使建筑散发出气味的原因。耦合越多，闻起来越香。
就是说：根本没有耦合通常会闻到性能问题。
这是我一直遇到的一种具体的体系结构/设计气味：直接从事务数据库进行分析和报告。
在某些情况下（即少量报告），这当然是可以的，但在许多情况下，报告和事务处理要求存在冲突。但是，由于这是一件简单/便宜的事情，因此报表直接从事务数据库运行。这在等式两边都引起了各种各样的麻烦。
顺便说一句，这在Enterprise LOB应用程序中很常见。我知道许多SMB都没有创建仓库和数据集市的资源或专业知识（忘记多维数据集或减少地图的设置），但是与我合作的许多大型组织都遇到了同样的问题。
在设计系统时，架构师确实应该意识到，报告（尤其是分析报告）和事务需求最好被视为单独的问题，而不仅仅是在数据库级别上结合在一起。