I/O无关紧要原则与插件式架构：构建变更防火墙

开发者常把GUI直觉性地等同于系统本身，因为GUI是唯一直接可见的部分——这是一个需要纠正的误区，核心原则是I/O是无关紧要的。以视频游戏为例，玩家的主观体验来自屏幕、鼠标、按钮、声音这些界面反应，但界面背后有一套复杂的数据结构和函数构成的模型，那才是游戏真正的核心驱动力；就算完全不显示在屏幕上，这个模型也应该能独立完成全部任务逻辑、处理全部游戏事件——界面对模型（也就是业务逻辑）而言无关紧要。因此GUI和BusinessRules之间同样该有一条边界线，箭头方向和[[数据库是业务逻辑间接使用的工具边界线应画在依赖箭头指向业务逻辑之处]]里的Database/BusinessRules关系一致：GUI依赖BusinessRules、而非反过来，这意味着GUI可以被替换成任何其他形式的界面，BusinessRules完全不需要了解这些细节。把数据库和GUI这两个例子推广，就得到了插件式架构的一般模式：系统核心业务逻辑与其他组件保持隔离独立，这些其他组件要么可以整体去掉、要么可以有多种实现（Web界面、客户端/服务器界面、命令行界面；SQL数据库、NoSQL数据库、文件系统）。这种插件依赖关系带来的收益可以用ReSharper和Visual Studio的真实案例说明：JetBrains（俄罗斯）开发的ReSharper插件与微软（华盛顿州雷德蒙）开发的Visual Studio是完全独立的两个团队，依赖关系是ReSharper的源代码依赖Visual Studio——这是一种不对称关系，ReSharper团队无法干扰Visual Studio团队，但Visual Studio团队却能单方面中止ReSharper团队的一切工作。这正是我们想在自己系统里构建的关系：只要GUI以插件形式接入业务逻辑，GUI一侧发生的变更就无法翻越这道”防火墙”波及业务逻辑。因此边界线应该沿着系统的变更轴来画——线两侧的组件理应以不同原因、不同速率变化，这本质就是单一职责原则的具体实现：SRP告诉我们该在哪里画边界线，本章的边界划分实践也正是依赖反转原则（DIP）和稳定抽象原则（SAP）的落地——依赖箭头永远从底层具体实现细节指向高层抽象。