各层运行位置的决策框架与复杂性增压器

选择每层跑在客户端还是服务器端，核心权衡是”响应性/断连可用性”与”维护简易性”的对抗：全部塞进服务器端（配Web浏览器前端）最容易维护，因为改动只发生在一个受控环境里，不用操心分发到各客户端、也不用管客户端上其他软件的兼容性；代价是每次交互都要走一次网络来回，断网时完全无法工作。往客户端搬（胖客户端）能换来更好的响应性和断网可用性，代价是版本升级和客户端一致性维护成本陡增。三层各有偏向：数据源层原则上留在服务器端（除非要支持断连操作，需要把服务器功能复制到功能强大的客户端上，并解决离线修改回传同步的问题）；表现层的位置基本被UI形式锁死——胖客户端就跑在客户端，Web界面就跑在服务器端（B2C系统尤其别无选择，只能靠服务器端HTML方案兼容任意来访者）；领域逻辑最自由，可以全在服务器、全在客户端，或者拆开——但拆开是最差选择，因为无法明确判断任意一块逻辑到底该去哪查，只有当确实只有一小部分领域逻辑必须在客户端完成、且能被剥离成不依赖其余系统的自包含模块时，才值得这么拆。Jens Coldewey提出的”复杂性增压器”点出了哪些因素会让这类决策的代价急剧抬升：分布式部署、显式多线程、范型差异（如对象/关系不匹配）、多平台开发、极限性能要求（如每秒百笔事务以上）——出现任意一个，开发和运维成本都会明显上升，能避免就该避免。

结构图：

flowchart TB
  Q["各层跑在哪？"]
  Q --> DS["数据源层：原则上留服务器<br/>断连需求才复制到客户端+做同步"]
  Q --> P["表现层：被UI形式锁死<br/>胖客户端→客户端；Web界面→服务器端"]
  Q --> DL["领域逻辑：最自由"]
  DL --> DL1["全服务器：易维护"]
  DL --> DL2["全客户端：响应好/可断连，但升级维护贵"]
  DL --> DL3["拆开：最差选择<br/>仅当可剥离成自包含模块时才值得"]
  CB["复杂性增压器"] --> CB1["分布式部署"]
  CB --> CB2["显式多线程"]
  CB --> CB3["范型差异(对象/关系)"]
  CB --> CB4["多平台开发"]
  CB --> CB5["极限性能要求"]