Hunt The Wumpus案例：从三组件模型到多API边界，GameRules成为最高层策略

“系统=UI+业务逻辑+数据库”这个三组件模型对简单系统够用，但稍复杂的系统组件数量远不止三个。以1972年的文字冒险游戏Hunt the Wumpus为例：如果想让游戏支持多语言，就需要把UI和业务逻辑之间用一种与自然语言无关的API解耦——多个UI组件可以复用同一套游戏业务逻辑，业务逻辑不必知道UI用的是哪种语言；类似地，游戏状态存储介质（闪存/云端/本机内存）的细节也不该让游戏引擎知道，需要另一个API隔开业务逻辑和数据存储。但语言并非UI变更的唯一维度——文字输入输出方式本身也会变（命令行、短信、聊天程序），这意味着还需要一条API把语言部分（Language）和通信部分（TextDelivery）隔开。这样系统里的抽象组件（虚线框）所定义的API，惯例上由其使用方的上层组件负责实现和维护，而非被使用方：GameRules定义的API由Language实现，Language定义的API由TextDelivery实现，同时反过来Language使用的Boundary多态接口由TextDelivery实现、GameRules使用的Boundary多态接口由Language实现——每一层的具体实现类（English/Spanish、SMS等）都实现了上层抽象组件定义的多态接口。去掉所有具体实现类只留API组件后，箭头全部朝上，GameRules自然坐落在顶层，印证了它是最高层策略组件这个事实：来自用户的信息经TextDelivery→Language转换成命令输入给GameRules；GameRules处理后把数据交给DataStorage存储，同时把输出向下经Language转成语言、经TextDelivery传给用户。这样系统被分成两路数据流——一路管用户通信、一路管数据持久化，两路在顶部的GameRules汇聚，GameRules是所有数据的最终处理者。

结构图：

flowchart BT
    TextDelivery --> Language
    Language --> GameRules
    DataStorage --> GameRules
    GameRules -.API由GameRules定义,Language实现.-> Language
    Language -.API由Language定义,TextDelivery实现.-> TextDelivery
    GameRules -.API由GameRules定义,DataStorage实现.-> DataStorage