对领域驱动设计的初步认识(七)
DDD的方向无疑是正确的,但是看了Eric的DDD以及banq的jivejdon源码后不禁又有了一些疑问。
"贫血模型"无疑是不对的,领域建模中的领域对象应该是有行为的。在jivejdon中看到的领域对象其实并没有多少行为,而大部分的领域行为都让Dao或者Repository占去了。这不仅让我有一种似曾相似的感觉,原来在service的那些方法以另外一种面貌出现在了Repository层中。从Dao或者Repository本来的字面意思上可以看出,Repository层仅仅是领域模型与数据库的隔离层,显然不应该包含领域逻辑的。
|
从以上代码可以看出,对于创建这个动作,Service并没有把它交给Forum对象,而是直接给了forumDao.在我看来,这是违背了DDD的本质的,应该由forum对象承接这个动作,然后才由领域对象再传给forumDao。
也许有人说,CRUD可以由领域对象直接承接动作,那更复杂的场景应该怎么办呢。呵呵,其实答案很简单,因为这个问题的答案已经在问题中说了,就是“场景”。场景是让领域对象具有行为的实际生存条件,所以DCI才是DDD中对于领域对象行为建模的有益补充。
我建议抛弃掉DDD中关于工厂的提法,只有这样才会让我们回归真实业务,那只是一种“创建场景”,而不仅仅是那所谓的“工厂模式”,因为复杂创建场景中还可能包含复杂的流程或者策略对象的东西。
|
以上“forumMessage.setCreationDate(displayDateTime);”部分应该属于领域业务逻辑,不应该出现在Dao中。
另外,我也不太赞同DDD中关于聚合的做法,因为保证领域模型内部对象的一致性并不是只有通过层层封装才能做到。在我看来,这种层层封装并不是领域内部的业务场景的真实反应,反而造成领域内部逻辑的复杂和僵化。在jivejdon中,Dao、Factory、Builder、Kernel之间的命名关系一直让我困惑,至少感觉逻辑很沉重,与业务逻辑对应关系也不清爽。
总结一下,DDD=Service+富领域的对象+基于事件的DCI+不含业务逻辑的仓储。
呵呵,其实jivejdon有很多值得我学习的地方,希望大家共勉。
[该贴被flyzb于2010-12-11 22:04修改过]