三种领域逻辑组织模式概览对比

领域逻辑的组织方式主要有三种。事务脚本：每个用户动作对应一个过程，该过程负责接收表现层输入、校验计算、存取数据库、调用其他系统，再把结果返回表现层；脚本内部可拆成共享子例程，但每个动作始终由单一过程驱动。领域模型：围绕领域中的名词（如租约、资产）建立类，校验和计算逻辑分散到各个对象自身承担，不再由一个过程统揽全局，行为分布在对象网络里。表模块：介于二者之间，围绕数据库表（而非过程或对象实例）组织逻辑，每张表只对应一个公共类实例，与记录集配合工作——客户先查询生成记录集，再用记录集构造表模块对象，调用时需附带记录ID区分具体是哪一条记录。三者优缺点各有侧重：事务脚本简单、事务边界清晰、易与简单数据源层配合，但逻辑复杂后容易产生重复代码、结构杂乱；领域模型能用继承/策略等技术从容应对复杂逻辑的持续演化，但上手门槛高、数据源层映射代价大；表模块提供了比事务脚本更多的结构、更容易发现冗余，且天然契合基于记录集的GUI/ORM工具（如.NET环境），但拿不到领域模型的细粒度面向对象组织能力。三者并不互斥，同一系统里用事务脚本处理简单部分、领域模型或表模块处理复杂部分是常见做法。

结构图：

flowchart TB
  A["领域逻辑组织模式"]
  A --> T["事务脚本<br/>过程驱动，每动作一脚本"]
  A --> D["领域模型<br/>对象驱动，行为分散到各对象"]
  A --> M["表模块<br/>表驱动，围绕记录集"]
  T --> T1["优:简单/事务边界清晰"]
  T --> T2["缺:复杂后重复代码/结构杂乱"]
  D --> D1["优:细粒度扩展(继承/策略)"]
  D --> D2["缺:上手代价高/数据源层复杂"]
  M --> M1["优:比事务脚本更结构化，契合记录集工具"]
  M --> M2["缺:无法用领域模型的细粒度OO技术"]