对多对多软件解决方案常见的批评是其架构过度复杂，在设计、抽象、实现、部署或其他方面造成不必要的复杂性、理解困难、维护不易、多余或错误。然而，过度架构的指控往往缺乏背景或支持性叙述，并可能成为工程师推卸责任的一种方便手段。本文探讨了有问题的架构的三种基本类型：不同的架构、错误的架构和过度架构，并对这些类型的特征和示例提供了见解。
对多对多软件解决方案经常听到的批评是，它架构过度，这意味着设计、抽象、实现、部署或其他方面不必要地复杂、难以理解、无法维护、不必要或错误。批评往往是无中生有，没有背景或支持性叙述；批评往往是持久的。
那么将解决方案标记为过度架构有什么好处呢？
通常，这是软件工程师的终极出狱卡，在没有客观分析甚至不了解当前实施情况的情况下，将超出预期的工作量和时间表的责任推卸给别人。不幸的是，高层领导通常会以同情的“啊，架构过度，我很抱歉”的耸肩来盲目接受解释，当最初的工程师无法填补需求、决策、实施等方面的空白时，这种方法尤其有效。
是的，最初实施的架构可能与您首选的架构（技术堆栈、业务假设、抽象等）正交，但您是否可以毫不含糊地说它是过度架构？自最初实施以来，贵公司的业务目标或技术方向是否发生了变化？需要考虑哪些非功能性需求？提交消息中有什么有趣的内容吗？
最重要的是，您担心的是架构过度还是发生了一些不那么危险的事情？嗯，我不确定！
软件工程师 软件工程师
如果你更喜欢维护现有代码而不是编写新代码，请举手。如果你喜欢维护别人的代码，请举手。啊，我想是的。
当被分配维护工作时——无论以何种形式——工程师都会寻找允许他们修改、重组、重写并总体上使工作更有趣的角度。如果责任表明过度变动、循环复杂度过高或代码确实变得无法维护，那么这是一个正确的决定。诚然，产品所有者和Scrum 主管不会高兴，但在某种程度上，过去的罪孽再也不能被忽视了。
公开称现有代码架构过度，你可能会如愿以偿。然而，偶尔有人会要求更深入的解释，这让人怀疑其原因，因为工程师：
不理解当前的实现，也不愿意努力去学习
不了解业务或技术要求或其他基本假设
不同意使用的设计模式或代码结构
不喜欢代码风格或格式，甚至不喜欢编程语言本身
而且，毫不奇怪，重写比预想的要大，因为具有讽刺意味的是，他/她必须最终理解现有的解决方案才能重新实现它：尽管你声称自己没有铺平道路，但不可避免地你可能需要这样做，而这在没有全面理解的情况下是不会显而易见的。您的组织真的准备好采用API First、微服务、NoSQL 或简历中添加的其他任何东西了吗？
工期越来越长，领导层越来越沮丧，其他重要工作被推迟和延期，这一切都是因为工程师坚持认为这是必要的。我们都见过这种情况，我们中的许多人都是始作俑者，而且这通常不是一个美好的故事。
但问题依然存在：它的架构是否真的过度了？
有问题的架构
软件工程学科中应用的架构有多种标签：例如，企业、系统、应用程序、软件、云和集成。更令人困惑的是，组织经常根据其内部需求定义架构学科，这使得很难明确定义每个学科的职责和界限。这绝对不是一个一刀切的比较。
话虽如此，如果您泛泛而谈，而不是试图在架构学科内定义具体内容，那么定义有问题的架构是可能的。我发现有三种基本类型的潜在问题架构。
1. 架构不同
架构不同的解决方案是指对解决方案中非功能性需求的解决方式存在不同看法的解决方案。针对云的解决方案应该是云原生的还是云无关的？稳定性和可靠性比吞吐量和性能更重要还是更不重要？支持资源是根据成本、功能还是两者来选择的？
您对底层架构的任何担忧或抱怨都必须与非功能性需求相平衡，因为非功能性需求对于成功的解决方案至关重要。您可能不同意非功能性需求；因此，您的担忧或抱怨可能只有在重新确定非功能性需求的优先级时才有意义。无论您的感受如何，只要满足非功能性需求，解决方案就是有效的。
即使您完全同意非功能性需求，不同的工程师也肯定会创建不同的解决方案：同步与异步、面向对象的继承与组合、功能性或基于 CRUID 的 API 端点 SQL 与 NoSQL、API First 与 MVC。这是主观的，因为每个解决方案本质上都是正确的；只是您的方法与我的不同。
“ Hello, World !” 可以用数千种不同的方式实现，每种方式都同样正确或错误，因此不同的工程师和架构师将以不同的方式处理每个问题。这是错的吗？不是。这是架构过度吗？如果非功能性需求得到明确识别和实施，可能不是。但您仍然可能不同意我设计和实施的内容。
2. 架构错误
识别架构不当的解决方案通常需要从构思到部署对有缺陷的实施进行解构：需求定义不明确或不明确、代码质量差、项目执行不力、时间表不切实际以及架构无用。问题（以及责任）通常是多方面的。
抛开这些复杂性不谈，错误架构的解决方案具有以下共同特征：
即使已经确定了非功能性需求，也不会予以解决。
组织内部不具备成功实施所需的技术技能和背景。
该架构需要在组织核心竞争力之外构建组件，尤其是在存在现有组件的情况下。
部署的解决方案不稳定，需要定期关注以避免中断。
维护和扩展依赖于被认为不可替代的个人。
如果您曾经参与过火车失事项目，您可能会认出其中之一。您还可能意识到，您认为架构错误的实际上是没有架构的。最重要的是，这些项目及其产生的解决方案通常无法挽救，与之相关的一切都是浪费时间。
3. 架构过度
是否有任何解决方案是过度架构的？很可能。这个电灯开关是不是有点过头了？对于我们大多数人来说，也许如此，但这个世界上的鲁布·戈尔伯格 (Rube Golberg)和创客们可不这么认为。
以下经验可能代表了过度架构；也可能只是错误架构，绝对是不同的架构。
问题陈述
在我担任独立软件顾问期间，我曾被聘为一位刚离职员工的补充人员。这位前员工为公司构建了第一个真正的 Web 应用程序，并设计、实施了一个自定义框架（大部分工作都由他完成）：他/她留下了示例实施和少量（没有？）文档（设计、使用等），剩下的员工不得不尝试收拾残局。
[对于阅读本文的千禧一代，请记住，早期的 Web 开发没有真正的标准或最佳实践，开源还处于起步阶段，当时还是蛮荒的西部，每个人都在寻找答案。性能不足的用户计算机难以应付简单的浏览器端脚本（DOM之前），每个浏览器供应商的浏览器都自由地解释 HTML 标准。那时Internet Explorer开始其恐怖统治（但不知何故至今仍然存在）。与今天完全不同。]
我的任务：拥有框架，了解它的秘密，并定义开发应用程序的路线图。
理解并内化
从 100K 英尺/30.5K 米的高度来看，概念上很简单：服务器端生成要创建的 HTML，由处理请求、响应、导航等的 Java Servlet 应用程序（框架）进行编排。在 50K 英尺/15K 米的高度，事情就没那么简单了。在 25K 英尺/7600 米的高度，事情就变得非常可怕了。
我越深入研究，担忧就越强烈。页面紧密耦合，看似微小的变化会迅速影响到相邻页面。页面直接生成 HTML，很难确保整个应用程序的一致性。更改默认框架行为依赖于找到相应的钩子，而这些钩子通常数量众多且令人困惑。编排在原始 servlet 引擎（Sun Java Web Server）中有效，但如果更改则无效（开始关注Tomcat 的性能）。本地开发需要定期同步其他工程师的代码，而当时的版本控制（CVS、Subversion、Visual Source Safe等）使同步变得困难。
我已经忘记了其他恐怖事件的担忧，但障碍令人望而生畏，成功的机会渺茫。必须做出艰难的决定。
决策时间
我的结论是：该框架仅适合用途（勉强），但不适合开发；任何继续的尝试都会让剩下的工程师不知所措，而且很可能永远无法完成。
值得赞扬的是，经理同意了，并决定减少损失。长话短说：我们设计了一个更简单、更专注的框架，在三周内，工程师们就可以开始在工作模型上开发应用程序，并在两个月后成功演示了我们的进展。最终，我们非常成功，并在退役前用于多个应用程序。
判决结果
认为原始框架架构过度的原因有：
缺少非功能性需求：没有护栏来控制设计和实施
自我驱动设计：尝试通过包含除厨房水槽之外的所有东西来展示你有多聪明
过于复杂：难以实施、维护和支持
缺乏差异化：架构功能并不是竞争差异化因素，并且会大大延长产品上市时间
您可能会说架构不当，或者架构不同，但这只是语义问题。无论如何，我们在改变策略之前做了应尽的调查，客观地解释了这一点，而不是仅仅说架构过度。
最后的想法
软件解决方案的架构千差万别，取决于许多外部因素：业务与软件商店、技术人员的经验和技能、可用技术、组织成熟度等等。这是意料之中的。
很多时候，人们在不了解工作背景的情况下就很快放弃了一项实施。正当理由可能证明部分或全部重新实施是合理的，但也可能是为了工程师的私利。作为负责任的软件工程师，我们应该证明工作努力最有利于组织，而不是为了软件而软件。这并不意味着除了功能和技术之外什么都不该被诅咒，而是意味着我们应该能够证明所提出的技术工作是合理的。调查、记录、叙述、证明。
