领域驱动设计: More Practice

DDD的关键问题是如何识别缺失的领域概念. Eric的书里提供了一些方法, 比如倾听表达用语, 检查不协调之处, 研究矛盾之处等等. 我们需要更多的实践来捕捉缺失的概念.

新实践: 检查更换编程框架对代码带来的影响.

这个实践基于以下的理念: 业务逻辑没有发生变化则领域模型也不应该变化. 因此如果更换编程框架造成了大量业务代码的变动, 则意味着有概念没有被封装在领域层.

这里并非鼓吹要应用程序可以支持动态的切换编程框架, 比如从一种ORM工具切到另一种, 或者从一种MVC框架切到另一种. 这里强调的是领域模型及领域概念应该独立于编程框架来表达, 虽然最终模型需要通过某种关联或适配被框架来调用.

举个例子. 公司在为客户提供不同的服务之前, 需要按照法律跟客户签署一系列的协议. 这可以是一个 legal compliance 的 sub domain. 如果客户没有签署协议, 则系统拒绝提供进一步的服务. 如果系统是一个网站, 则检查客户的协议签署情况以判断是继续提供服务还是拒绝的逻辑可以放在Filter中(几乎所有web编程框架都提供了基于管道和过滤器的架构). 但如果这样的话, 当我们更换web框架时需要把这部分逻辑挪到新框架下的filter中. 因此更好的做法是把这部分逻辑挪进领域模型, 可以建模成规则, 来表达每一条需要遵守的法律约束, 最终可以用领域层的管道和过滤器连接起来.

我们不必真的更换编程框架, 只需假象一下. 之前有类似的实践, 是假想需要为系统提供不同的UI, 比如一个Web UI和一个命令行UI, 来促使业务逻辑不要和UI代码耦合在一起. 实践是类似的, 角度不同.

 

新实践: 关注对基础类型的操作.

频繁操作基础类型, 尤其在不同的场合以同样的方式来操作基础类型, 通常意味着领域概念的缺失. 比如字符串类型. 如果你发现经常需要取字符串的某一段或者定位某个特定子串, 则很可能是把领域概念编码在作为实现的字符串身上了. 事实上, 除了在输入输出或者Context的边界交换数据时, 不应该有任何字符串的操作.

另一个例子跟我司面试题有关, 计算金额时的舍入. 如果舍入是某种会计规则所明确要求的, 则应该对其显式建模, 而不是直接在计算时用些round()函数来隐式的表达.

 

Working on more practice...