21 Screaming Architecture

想象下你现在在看一个建筑的蓝图，这个文件是设计师准备的，提供这个建筑的计划。这些计划告诉你什么？
如果你眼前的图纸是独栋住宅，你一眼就会看到正门、通向客厅的门厅，可能还有餐厅。不远处通常会有厨房，紧挨着餐厅；厨房旁或许还有小就餐区，再旁边多半是家庭活动室。看到这份图纸，你绝不会怀疑：这就是家。这份建筑设计分明在大声告诉你：“住宅”。
再假设你看的是一座图书馆的设计。你会看到气派的大门、图书借阅柜台、阅览区、小型会议室，还有一间间连绵的藏书廊，摆满书架容纳所有书籍。这份设计也在大声宣告：“图书馆”。
那么，你的应用架构在 “大声诉说” 什么？当你看着项目最顶层的目录结构、最高级包下的源码文件时，它们在大喊：“这是医疗系统”“这是会计系统”“这是库存管理系统”？还是在大喊：“这是 Rails”“这是 Spring/Hibernate”“这是 ASP”？

软件架构的主题

回过头去读一读伊瓦尔·雅各布森那部关于软件架构的开创性著作——《面向对象软件工程》。你会注意到这本书的副标题：用例驱动方法。雅各布森在书中明确提出：软件架构是支撑系统用例的结构。就像一栋住宅或一座图书馆的设计图纸会直白地彰显出建筑的使用场景一样，一款软件应用的架构也应当清晰地体现出该应用的用例。

架构无关（或本应无关）于框架。架构不应当由框架来定义。框架只是可供使用的工具，而非需要遵从的架构范式。如果你的架构基于框架，那它就无法立足于你的业务用例。

架构的目的

优秀的架构以用例为核心，让架构师能够安全地设计支撑这些用例的结构，而不必过早绑定特定的框架、工具与运行环境。再以房屋设计为例：建筑师首要关心的是房屋的实用性，而非房屋是否用砖砌成。事实上，建筑师会刻意留出余地，确保在设计满足使用需求之后，房主仍能后续决定外墙材料——砖、石材还是雪松木。

核心思想：

1.架构应该说业务，不说技术。看代码顶层结构应该能一眼看出这是医疗系统，财务系统，而不是Spring系统，就像看建筑蓝图一眼就知道这是住宅还是图书馆，而不是看用了什么砖。
2.架构的核心是支撑用例，不是支撑框架：软件架构的本质是为业务用例服务的结构，框架知识工具，不能反过来定义你的架构，架构被框架绑架=业务被技术绑架。
3.好的架构要把技术决策尽量往后拖：先把业务逻辑，用例结构定清楚，数据库，Web框架，服务器，ORM这些都可以晚选，再改。业务稳定，技术灵活。
4.Web只是交付方式，不是架构：Web只是一种IO渠道，不是系统本身。架构应该做到：不改动核心，就能在Web，桌面，控制台，接口服务之间切换。
5.框架要被你控制，不能控制你：不要全盘交给框架，不要让框架渗透到业务核心。要把框架隔离在边缘，保护业务逻辑纯净。
6.业务逻辑必须独立，可测试：实体，用例，业务逻辑，不依赖数据库，不依赖Web，不依赖框架。不用启动，不用连数据库就能完整测试业务逻辑。

好的架构可以让你不必在项目早期就敲定是用 Rails、Spring、Hibernate、Tomcat 还是 MySQL，并且即便后期改变主意也十分容易。好的架构会突出业务用例，并将用例与外围关注点解耦。

那 Web 呢？

Web 是一种架构吗？你的系统运行在 Web 上，这一事实就决定了系统架构吗？当然不是！Web 只是一种交付方式——一种输入输出设备——你的应用架构也应当如此看待它。应用通过 Web 交付只是一个细节，不应主导系统整体结构。甚至，是否采用 Web 交付这一决策本身也应当延后。你的系统架构应尽可能与交付方式无关：无论是做成控制台程序、Web 应用、富客户端，还是 Web 服务，核心架构都无需大幅改动或复杂化。

框架是工具，而非信条

框架可以强大且实用。框架开发者往往对自己的作品深信不疑，他们编写的使用示例也都站在忠实拥趸的视角。其他讲解该框架的作者也多是其追随者，向你传授“框架式”的开发方式。他们通常会主张全盘采用、深度渗透，让框架包办一切。

这绝不是你应采取的立场。

你要以审慎、挑剔的眼光看待每一个框架，保持怀疑。诚然它可能带来便利，但代价是什么？问问自己该如何使用它，又该如何保护自己不受其束缚。思考如何坚守架构以用例为核心的原则，制定策略，避免框架反客为主接管整个架构。

可测试的架构

如果你的系统架构围绕用例构建，且与框架保持距离，那么你就可以在不依赖任何框架的前提下，对所有用例进行单元测试。运行测试不必启动 Web 服务器，不必连接数据库。实体对象应是简单普通的对象，不依赖任何框架、数据库或其他复杂组件。用例对象负责协调实体对象，最终这一切都能脱离框架的复杂依赖，在原生环境下完成测试。

结语

你的架构应当向阅读者讲述系统本身，而非你在系统中使用了哪些框架。如果你在开发一套医疗系统，当新程序员查看代码仓库时，第一印象应当是：“哦，这是一套医疗系统。”他们可以完整了解系统的所有用例，却不必知道系统的交付方式。他们或许会问你：

“我们看到了一些类似模型的东西——但视图和控制器在哪里？”

而你应当回答：

“哦，那些都是暂时无需关心的细节，我们以后再做决定。”