知识卡片

领域模型的"理论体系转换"

普通读书笔记卡

内容

从事务脚本转向领域模型,不只是换一种代码组织方式,而是一次面向对象程序员极力鼓吹的”理论体系转换”(paradigm shift):事务脚本里是一个过程掌控用户某个动作的全部逻辑,你在一个地方就能看完整个流程;领域模型里则是每一个对象各自承担一部分相关逻辑,行为分散在对象网络中——不习惯这种组织方式的人,学习初期常常要”从一个对象冲到另一个对象”才能找到某个行为到底在哪实现,这种挫折感是真实存在的代价,而非危言耸听。书中用同一个”按合同和产品种类计算收入确认”的例子对比两种模式的顺序图:事务脚本版本里calculateRecognitions方法包揽全部工作,底层对象只是搬运数据的表数据入口;领域模型版本里则是多个对象层层转发行为,直到某个策略对象创建出最终结果——领域模型的价值正在于此:以后新增一种收入确认算法,只需新增一个策略对象,而事务脚本则要在已有脚本的判断逻辑里不断堆条件分支。可迁移启发:评估要不要切换到某种新范式时,除了看它长期能带来的扩展收益,也要诚实评估团队适应这种”体系转换”所需要的学习摩擦成本,这个成本是真实的、会持续数月,不是一次性的。

参考来源

- 位置:《企业应用架构模式》第一部分"表述"之"第2章 组织领域逻辑"(源文件:_epub-src/OEBPS/Text/000015.html) - 结论依据:原文说明"用领域模型而不是事务脚本正是面向对象的程序员所极力鼓吹的'理论体系转换'的精髓……如果不习惯领域模型,开始学习使用它时会充满挫折感,为了找到行为在哪里,你会从一个对象冲到另一个对象",并用收入确认的顺序图对比案例说明"当增加新的收入确认算法时,只需增加相应的新策略对象即可。而使用事务脚本则需要在脚本的判断逻辑中增加许多新的条件",直接支撑本卡结论。 - 原始内容:如果不习惯领域模型,开始学习使用它时会充满挫折感,为了找到行为在哪里,你会从一个对象冲到另一个对象……通常,开发者要在采用这一模式的项目上工作数月后才能转变他们的思维方式。