软件开发架构模式浅谈：一些思考和实践记录

最新推荐文章于 2024-06-21 21:06:48 发布

数据库技术分享者

最新推荐文章于 2024-06-21 21:06:48 发布

阅读量2k

点赞数

CC 4.0 BY-SA版权

文章标签：架构

本文链接：https://blog.csdn.net/weixin_43970890/article/details/121992711

本文作者探讨了软件开发中的架构模式，特别是MVC模式及其在不同场景下的实践。作者指出，随着业务复杂度增加，单一的MVC模式可能不足以应对，提出了MVVM模式作为解决方案，强调了可测性在保障产品质量中的重要性。文中还分析了业界大厂对于MVC的不同理解和实践，以及如何通过不同架构模式解决复杂逻辑的商家经营工具的质量问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一背景和问题

我个人平时会比较慎用“架构”这个词

一方面是觉得业界有很多架构大师和架构模式，而我的认知和实践有限；
另一方面是因为这个词看着挺高大上、有点务虚，如果不结合实际场景的具体问题来讨论，容易陷入“PHP是最好的语言”这样的辩论赛中。而不同场景中又有各自的问题，程序员们通过自己的理解和思考、针对实际场景对一些架构模式进行了扩展实践，以此来解决遇到的问题，也会基于同一个模式延伸出一些派生概念。

兵无常势，水无常形。所以，我个人的观点是：以要解决的问题为出发点，去讨论我们要采用的架构模式（技术方案）。

另外，由于我们是站在很多巨人肩膀上的，讨论时可以站在一些如SOLID等软件设计/开发原则的基础上。

写这篇文章，我也是从解决一些问题的目的出发的：

最近和团队同学讨论了相关话题，虽然大多数同学在实践上基本一致，但具体到话术、名词概念和具体使用的理解和实践上有些差异（这是很正常的，因为业界对同一个模式的理解和实践也不同）。我结合一些实际编码场景做了一番陈述，为了避免后续重复大费口舌，所以打算写下来，以后有需要直接发文章链接。
由于我个人的认知和实践有限，所以也希望能抛（huan）砖（ying）引（lai）玉（pen），让我学到更多。
虽然同一个架构模式在不同业务/技术领域的实施会有区别，但同一个团队内应该保持一致性，因为这样有助于日常的code review、功能模块的交接backup等活动，尤其是有利于使用统一的单测建设方案来保障我们的产品质量。
实际问题：我最近在开发商家合并发货的功能，但由于之前基础发货功能的界面和逻辑并不是我开发的，所以我在修改原有代码、支持有非常多细节逻辑的合并发货能力时，就在担心对原有发（zhong）货（yao）能力的影响。而这时候，如果有单测的保障，我就可以更放心地进行功能升级改造了 —— 别说更复杂的合并发货能力了，而这类诉求在复杂的交易场景里很普遍。

提炼一下我遇到的具体问题：

在由不同开发人员持续迭代、进行功能升级的软件开发活动中，如何保障具有复杂逻辑的商家经营工具的产品质量。

软件开发活动是整个流程的核心环节：接收产品和视觉设计需求/变更作为输入，然后输出客户可用的终端产品。

而统一的软件开发架构模式，则是我们保障软件开发质量的基础。（这里就不具体展开WHY了）

由于讨论的是具体面向客户使用的业务场景，少不了客户操作交互的视图层（View），所以我从MVC开始谈起。

二从表现层的MVC谈起

虽然我平时比较慎用“架构”这个词，但我平时喜欢随手拍一些建筑物。因为建筑之美，会让我联想到软件的架构也应该有美感，毕竟Software Architecture这个概念也是起源于Architecture。
这时候，架构这个词就会给我一种接地气的感觉：有多少块砖，每块砖做什么用、放到哪里去，这块砖和那块砖怎么黏在一起或互相支撑。当然，由于软件的可移植性、可复用性，从某些角度来讲，软件架构相比建筑架构有其更复杂的地方。

MVC诞生至今已经超过40年了（Since 1979），10多年前就得到过很广泛的讨论和实践，穿越时空到今天肯定有其反脆弱性和内在核心价值。虽然如今乍看起来好像已经过气、被讨论过千百遍了，但仍然有很多程序员会有不同理解和看法，或多或少。这是很正常的，上面也提到了部分原因，这里具体再展开下。

1 MVC在经典三层架构里的位置

MVC是一种通用架构模式