按层水平解耦与按用例垂直切分的矩阵式解耦模式

[[SRP的真正含义是只对一类行为者负责而非只做一件事]]和[[CCP共同闭包原则是SRP在组件层面的再度阐述]]在系统级别落地时形成两个正交的切分方向。水平方向：用户界面的变更原因显然和业务逻辑无关，因此该被隔离；业务逻辑本身还能再分——与具体应用紧密相关的逻辑（如输入字段校验）和与领域更普适相关的逻辑（如计算利息、清点库存）变更速率和原因不同，也该分开；数据库及其查询语言、表结构则是纯粹的技术细节，与业务规则和UI都无关，变更原因和速率同样独立。这样系统就被解耦成若干水平分层：UI界面、应用特有业务逻辑、领域普适业务逻辑、数据库。垂直方向：用例本身也是变更的独立原因——添加订单和删除订单几乎肯定因为不同的理由、以不同的速率变化，因此系统也该按用例切分；每个用例恰好会用到UI、应用特有逻辑、领域逻辑、数据库这四层里的一部分，因此用例是横切这些水平分层的垂直切片。把两个方向叠加，就得到一个矩阵：只要按变更原因彻底解耦（水平分层+垂直用例），就能持续给系统添加新用例而不影响旧用例——如果连UI和数据库部分也按用例分组，新增用例波及旧用例的可能性就更低了。这套解耦对运行目标也有直接好处：良好隔离的用例天然把高吞吐量需求和低吞吐量需求分开，UI/数据库从业务逻辑分离出来后可以运行在不同服务器上，需要更大带宽的部分也能独立扩容成多实例——只是要真正跨服务器运行，被隔离的组件就不能再共享同一处理器的地址空间，必须变成独立服务、经网络通信（这正是面向服务架构/微服务的由来，但作者强调这里只是”有时候需要切到服务层次”，不是在鼓吹SOA或微服务就是最优解）。

结构图：

flowchart LR
    subgraph 水平分层
    UI[UI界面]
    AppLogic[应用特有业务逻辑]
    DomainLogic[领域普适业务逻辑]
    DB[数据库]
    end
    subgraph 垂直用例切片
    AddOrder[添加订单用例]
    DeleteOrder[删除订单用例]
    end
    AddOrder -.横切.-> UI
    AddOrder -.横切.-> AppLogic
    AddOrder -.横切.-> DomainLogic
    AddOrder -.横切.-> DB
    DeleteOrder -.横切.-> UI
    DeleteOrder -.横切.-> AppLogic
    DeleteOrder -.横切.-> DomainLogic
    DeleteOrder -.横切.-> DB