fety07
2007-10-22 10:45

感谢banq和各位.我找到了我的缺口,由于还是按照以前的老办法"找名词,写对象",导致了"面向数据表分析",带着寻找突破口的渴望,读了<<领域驱动设计>>,我知道了为什么以前想建领域模型,但模型让人看起来不伦不类,连我自己都不喜欢,看了<<领域驱动设计>>前几章,有点豁然开朗的感觉.

我有一些感悟,请前辈指教:

建领域模型,就像解数学题一样,只有你知道解法时,才能一步步走向结果.当下次再碰上这类问题,就知道这么走.建领域模型时,它也有"解法",这就时建模指导原则,作者总结出了一些模式,知道了指导原则,我们就可以组织对象.当然要熟悉需要经历很多的,就像解数学题一样要多练习.

banq
2007-10-22 15:29

从另外一个方面说:就是根据OO设计选择框架,如果一个框架不符合OO分析设计的思路,那么它就是一个不适合OO的框架 。

IBatis从一个极端观点来说就不是一个真正OO框架,也不是一个O/Rmapping框架,它不会强迫你使用OO思维来思考,然后你就用了数据库ER思维,所以,才感觉到"框架束缚了OO思维"。

所以,如果想使自己强迫使用OO思维,选择DDD领域建模性质框架,包括Hibernate这样ORM框架。忘记数据库和数据表概念。

hyhongyong
2007-10-22 15:55

框架是你要用的工具,OO是你对领域的抽象。

工具不用在应该用的地方,有的时候感觉会妨碍OO,但真正的原因应该是你没有认识到它们的关系。

没有纯OO的框架(如果有,也是不实用的)。

同样,就是处理领域问题,也不一定要全部OO,但你一定要清楚那一部分。

fety07
2007-10-22 17:22

>同样,就是处理领域问题,也不一定要全部OO,但你一定要清楚那一部分。

由于发现了DDD的魅力,所以解决问题是总是带着如何构建一个领域模型的观念,如果问题简单了,反而持怀疑的态度,这种方案是不是领域模型.其实有一些问题确实很简单,是我把它复杂化了.

[该贴被fety07于2007-10-22 17:23修改过]

banq
2007-10-23 15:27

>其实有一些问题确实很简单,是我把它复杂化了

呵呵,不要自责,你勇于反省已经很好,将简单问题复杂化是因为我们以前被灌输的所谓知识阻碍了我们的眼睛,本来很简单质朴的东西,却被数据数学一些高深理性的知识扭曲,DDD有时就是一种生活自觉,这也是你在Evans这本书中找不到类似数学那样公式定理的原因。

2Go 上一页 1 2