本文讨论了几个看似吸引人但在实践中往往失败的工程概念。以下是所提出的关键理念的摘要：
可插拔架构：
组件可以轻松更换的观念往往具有误导性。真正的可插拔性需要同时设计多个实现，而这个前提条件很少会同时具备。
添加 API：
过渡到带有 API 的平台非常复杂，需要转变思维方式。许多公司认为创建 API 会吸引开发人员，但这并不能保证。
成为 API 提供商本身就是一种整体思维和技能，您需要不断牺牲兼容性和互操作性来换取功能，您会因为遗留行为或性能特征而受到事物变化的限制，而且您基本上永远无法改变现状。
正确使用 API 需要大量工作和复杂性：
- API 需要精心设计，否则客户端可能需要多次调用 API，而一次调用就足够了。或者 API 可能会令人困惑，人们会错误地调用它或根本无法使用它。
- API 需要身份验证和授权。这意味着设置 OAuth2 或至少拥有安全的 API 令牌生成、存储和验证。
- API 需要安全地处理数据，否则您将泄露不应该泄露的数据，或者允许不应该泄露的修改。
- API 需要高性能，否则您的数据库可能会不堪重负。这可能涉及缓存，这会增加缓存失效的复杂性以及支持缓存的其他服务器/进程。
- API 需要进行速率限制，否则不规范的客户端将会损害您的 API。
- API 需要详尽的文档，否则就毫无用处。您甚至可能需要添加 SDK（不同编程语言的库），以便人们更轻松地使用 API。
- API 需要良好的错误消息，否则刚开始使用的用户将不知道为什么他们的调用失败。
过度抽象：
虽然抽象可以简化问题，但过早或过度引入抽象可能会导致维护挑战和效率低下。
异步操作：
虽然异步编程很重要，但独立管理它往往会导致难以重现的错误和数据完整性问题。
访问控制实施：
开发后设计访问控制是有风险的，并且通常会导致以后进行大量的重新设计工作。
数据同步：
跨多个平台或设备同步数据非常复杂，并且常常会导致无法预料的挑战。
跨平台开发：
构建可跨不同平台无缝运行的应用程序通常需要大量资源，并且随着系统的发展可能无法提供预期的结果。
本机功能：
此概念表明框架可以允许开发人员在必要时使用本机功能；但是，它通常会使状态管理和数据完整性变得复杂。
网友1：
- 悲观主义和厌倦的愤世嫉俗。我明白，我也有过这种感觉，有时很难说服一个热切的工程师放弃一个坏主意。
- 这是一份系统理念清单，这些理念比人们最初想象的要难，应该认真对待，而不能漫不经心。
网友2：
我想补充一下“领域驱动设计”——试图让应用程序与业务结构相匹配，从而将业务设计锁定在原地，这只会酿成灾难。
- 如果您的业务规模较小或停滞不前，您可能不会注意到任何问题。如果您的业务成功和/或发展壮大，您会立即后悔尝试使用与您已经过时的业务实践相关的可怕的描述性名称来构建域。
- 相反，围绕功能层进行设计（几十年来我们一直在这样做，久经考验），并尽可能将业务逻辑保留在配置中、数据库中的行和用户工作流中，这使得它们非常灵活。
包含配置、工作流等所有业务逻辑的高度抽象的设计将使您的系统极其灵活？
- 这些排列组合很快就会爆发成一个由人们依赖的未知/意外行为组成的迷宫。
- 这也使得新开发人员入职和更换开发团队的成本难以承受。
您的组织将使用两种不同的语言，大多数看似简单的“功能要求”会破坏您的抽象，
- 要么成为大规模的系统重新设计/重新架构，
- 要么成为“让我们破解这个抽象，这样它现在是一个更安全、更小的更改”。
网友3：
- 离开具体上下文情况，谈抽象与模式一无是处。
- 为何人们还在反复谈论，是掉入辩证陷阱了吗？不，是因为他们缺少“上下文Context为王”的意识。