开发软件就像一次旅行，在这个过程中，团队需要不断做出决策，既包括他们所构建产品的功能（即 MVP，最小可行产品），也包括支撑该 MVP 所需的架构（即 MVA，最小可行架构）。
采用这种方法的主要挑战在于，我们必须足够快速地构建出可发布的产品，以便团队能尽快获得关键反馈。
当团队寻求更快捷的获取反馈的方式时，他们必须决定，是选择一条他人已经走过的路径，还是另辟蹊径、自行探索。
有一种重用架构的方式，那就是使用其他团队已经采用的相同的平台或框架。一个优秀的平台或框架能让每个团队专注于自身独有的“增值部分”。重复造轮子毫无价值，因此忽视现有的平台和框架团队，实际上就是在浪费精力，未能聚焦于只有他们自己才能完成的事情。
平台和框架就像已经铺设好的道路，它们能够帮助团队在开发旅程中更快地前进，并提供定义明确的“出口匝道”或扩展点，让团队可以在需要时对平台进行扩展以满足自身的需求。但它们也附带一些副作用，可能使其变得不够理想。
团队需要针对如下问题做出判断，即何时（如果有的话）应当离开他人铺设的道路，通过扩展平台/框架，甚至开发全新的平台/框架，走出自己的路。
当团队以平台或框架作为其软件架构的基础时，所面临的挑战在于，选择一条最接近其目标目的地的“铺好的路”（即平台或框架），同时尽量减少绕行或新建工程。但是，MVP 的问题是这个“目的地”在项目初期往往是未知的。
平台和框架会替你做出许多决策，但其中有些是你根本不需要的
平台和框架通常具有一定的倾向性，这意味着在构建 MVA 时，团队需要做的架构决策更少。关键问题在于，团队能否接受平台开发者所做的那些决策？理想情况下，团队应审视自身所需的架构决策，并与平台已做出的决策进行对比。
这带来了两个重要的挑战：
团队往往会在实验获得的经验反馈中，逐步发现他们真正需要做哪些决策；
平台开发者所做的决策并不总是明确或最终的，尤其当平台提供了扩展点，要求使用团队自行填充代码时更是如此。在“铺好的路”这一隐喻中，这些扩展点正是团队可以偏离主路、走上自己方向的地方。
许多平台的决策是无害的，只要不影响团队必须满足的质量属性需求（QAR），就可以接受甚至忽略。判断这些决策是否会造成损害的唯一方法，就是通过实验暴露平台在哪些方面未能达成系统的目标。由于平台开发者所做的决策常常未被记录，甚至是未知的，所以团队必须要测试他们的系统（包括所依赖的平台），以确保架构目标（即 QAR）得以实现。
即使技术上可行，扩展平台或框架也可能非常复杂。其他使用该平台或框架的人可能不同意你所提出的决策及相关变更，或者他们可能更偏好其他方案，而这些方案又无法满足某些团队的实际需求。这也是为什么存在如此多功能相似的平台和框架的原因之一。
此外，当团队决定扩展某个平台或框架时，他们实际上做出了一个隐含承诺，也就是长期维护这些扩展。他们必须将这种成本和所需的时间/精力纳入决策考量。这包括未来升级应用以适配平台/框架新版本的成本和工作量；若不及时升级，可能导致应用崩溃、安全漏洞无法修复，也无法利用新版本在性能和可扩展性方面的改进。
平台和框架能节省时间，直到它们无法做到这一点为止
在我们的简化视角中，平台是指应用程序运行所使用的软件环境（以及提供支撑的基础设施），平台的一个样例就是 Amazon Web Services（AWS）。框架则是应用程序（或其一部分）部分完成的“骨架”，团队在它的基础上添加自身特定的业务逻辑，例如 Java Spring UI 框架。大语言模型（LLM）也可被视为一种平台，团队通过提示词（prompt）对其进行扩展。平台和框架通过提供大量现成的能力，简化了应用程序的开发。
但有时候，团队需要的功能与平台或框架所提供的有所差异，举例来说，LLM 可能无法处理团队所需输入类型，比如，需要处理电话通话的音频并响应指令。LLM 在录音室环境下表现良好，但面对在嘈杂的机场录制的语音时，可能就无法工作。团队需要先构建音频降噪过滤器，但随后可能发现这些过滤器仍不足以解决问题。此时，他们就不得不训练自己的 LLM，以便使用包含“噪声”的对话数据。
用“铺好的路”作比喻，LLM 提供了一条已被验证的路径，但它无法带领团队抵达真正想去的地方。一旦发生这种情况，团队别无选择，只能在如下三种方案中做出选择：尝试扩展该平台（如果可行）、寻找另一个平台，或者从头构建自己的平台。
他们的挑战在于，需要花费一定的时间才能判断，究竟是基于现有平台继续开发更高效，还是必须为自己的场景构建独特的方案。他们的选择受限于平台开发者所做的决策。如果能接受这些决策，那么基于平台开发可能是最佳选择；但如果不能接受，那么在此基础上开发就是在浪费时间，而时间，恰恰是他们最宝贵的资产。
帮助厘清替代方案的三个关键问题
MVP 和 MVA 本质上是对潜在解决方案的“下注”。它们可能正确，也可能错误，而评估这些“赌注”是否成功的唯一方式就是实验。以下三个关于MVP的核心问题，有助于判断平台是否满足你的需求：这个产品值得构建吗？它能否在预期负载下实现可扩展性和性能？ 它是否具备长期可维护性？
图 1：帮助确定架构决策的三个问题
团队在评估某个平台时，应结合这三个问题进行思考：
该平台有助于 MVP 的开发，还是阻碍 MVP 的开发？平台可能提供面向用户的功能，简化 MVP 的开发，但也可能附带团队无法接受的架构决策。借用道路的隐喻来说，唯一的方法是先沿着这条路走一小段，通过架构实验，检验平台所做的决策是否契合团队对 MVA 的需求。
该平台能否在预期的负载下实现可扩展性和性能？这里的难点在于，通常只有通过实验，你才能真正了解自己的可扩展性需求。借用道路的隐喻来说，你往往并不清楚自己需要的是一条车流稀少的双车道乡间小路，还是一条能够承载海量车流的高速公路。
基于该平台构建的架构是否具备长期可维护性？平台的演进速度通常比具体的业务系统更慢，因为它们的变更往往需要社区共识。当平台无法快速调整以满足需求时，团队就需要有明确的机制来扩展平台，直到平台本身能够做出相应修改。
这些问题不应该仅仅停留在激发思考和讨论的层面，必须通过实验进行实证评估。在实践中，这些实验体现为可执行的测试，可以在系统构建过程中持续运行。频繁对系统进行测试，以评估当前架构是否仍然适合目标用途，有助于避免后期出现不可控的大规模返工。
尽管上述三个问题看似按线性顺序展开，但实际上它们构成了一个循环（如图 1 所示）：针对性能/可扩展性和模块化所做的调整，不应危及整体解决方案的有效性。
结论
平台就像一条现成的道路，可以让团队在交付 MVP 的旅程中更加轻松，但前提是，这条路确实通往他们想去的地方。团队在使用平台时面临的核心挑战在于，至少在项目初期，他们并不完全清楚自己的目的地，因此也无法确定平台所提供的“铺好的路”是否能带领他们抵达那里。
判断这条道路是否适合其 MVP 的一个重要方法，就是先走一小段，看看方向是否仍然正确，而这个“正确的方向”，正是由团队的质量属性需求（QAR）所定义的。
最终，团队不可避免地会在某个时刻离开平台所提供的“铺好的路”，走出自己的路径。通过实验，他们可以判断何时、何地需要这样做，是扩展平台以满足自身需求，还是开发平台完全未提供的全新解决方案，甚至彻底替换掉原有的平台。
原文链接：
The Architect’s Dilemma: Choose a Proven Path or Pave Your Own Way?
