判断该不该用工作单元的技术演进路径

工作单元要解决的根本问题是”记录哪些对象被操作过，以便知道要把哪些数据同步回数据库”，但这不是唯一的解法，几种方案的成熟度依次递进。最原始的方法：每改动一个对象就立即显式保存——简单直接，但代价是数据库调用次数可能远超预期，如果同一个对象在流程里被改了三处，就会触发三次数据库调用而不是一次。改进一步：把更新操作留到最后统一做，为此需要记录下所有被改动过的对象——如果只用普通变量做这件事，变量一多就迅速失控，这种做法和事务脚本配合尚可，但很难用在领域模型这种对象网络更复杂的场景里。再进一步：给每个改动过的对象打上”脏”标记，事务处理完后统一遍历找出所有带脏标记的对象写入数据库——这个方法的价值取决于”找出脏对象”这件事本身有多容易：如果所有脏对象都在一个单一层次结构里，遍历这个结构就够了；但要跨越一个更一般的对象网络（比如领域模型里错综复杂的关联关系）去查找，就变得困难。工作单元则是这条演进路径的终点：把所有相关信息集中放在一个地方管理，一旦启用就不用再为”怎么记录、怎么找到该写的对象”这件事操心，还能顺带充当更复杂场景（比如跨越多个系统事务的业务事务，需要配合乐观/悲观离线锁）的固定处理平台。

结构图：

flowchart LR
  A["每改动即保存<br/>调用次数远超预期"] --> B["变量记录待改动对象<br/>变量一多难管理，难配领域模型"]
  B --> C["打脏标记+事后遍历<br/>难在跨复杂对象网络查找"]
  C --> D["工作单元<br/>信息集中一处<br/>可作为复杂并发场景的处理平台"]