youway
2010-04-21 23:57
简单说两句吧,纯属个人理解!

借一句古语当引子:止而后有定,定而后能静,静而后能安,安而后能虑,虑而后能得!

从大粒度下看,模型会分解成两大块:

1. 静态特征:domain 大体从描述业务数据开始进行驱动;

2. 动态特征:service 大体上是业务操作的集合,形成服务层。

有些操作会放在domain的类中, 那是常常是因为,数据与操作的生命周期都要受同一个对象生命周期的限制; 而有很多操作方法会放在service层类中, 那常常是因为, 数据与操作的生命周期不拘束在一个对象生命周期中,使用灵活,而且这些类型本身就是方法的集合,适合提炼出接口,做好层与层之间的分离。

从小粒度去看,类分为两大块:

1. 静态特征: 属性(数据)

2. 动态特征: 方法(操作)

考察属性和方法如果分离,就意味着数据与操作朝着各自更抽象更灵活的方向去发展,尤其方法,它适用数据的范围更广,重用性更强,继而演化或沉淀出方法(更大粒度看服务)不变,而应对千变万化的业务数据的架构来...

[该贴被youway于2010-04-21 23:57修改过]

taochenpfj
2010-04-22 09:00
当初我看到banq老师写的关于dci的文章,就考虑到如果能有相应的针对不同data对象(或者是业务对象)的context,那么很多问题就会迎刃而解,但是有发现对于置于某个context的业务对象,如果它随着不同context变化,那么势必要有非常庞大的接口支持(当业务上下文变化比较大,比较多时,尤其如此)

DDD的那本书,继续看下去,现在看到service,module,这些东西还是比较浅的,还要继续下去

如各位所言,不管是实体还是值对象,还是service,这些对象之间的业务区分不是非常明显,尤其是没有经过业务证明,就不是非常好区别

klcwt
2010-05-26 10:58
2010年04月20日 16:53 "Antinomy"的内容
鄙人以为,统一语言是需要和具体使用用户一起建立的。DDD强调抓住最核心的内容,让其在用户和开发人员心里有个统一的模型(毕竟需求变化大多来自使用的用户。。。)。太拘泥UML和建模工具往往会分散了注意力。所以DDD一书都没有用很正规的工具就画, ...

Antinomy 正解。

DDD是一种介于分析与编码之间的工具,要让分析与设计互相影响,同时不失去对系统业务核心的理解。

spell
2010-05-27 17:03
DDD用来做前期的需求和业务分析是不错,但是用DDD的方式来做开发,简直是自虐,我绝对不会逼自己和兄弟们用DDD的方式来开发项目,这样对项目来说会陷入危险的境地。如果自己对这个感兴趣的话,可以自己做个简单的留言版来试验下,这个是个人自由,但是软件开发是集体行动,所以考虑的因素会多些。如果感觉对象贫血,那你就把对象聚合下吧,而且还可以提供除set和get外的其他方法,这个完全是你的自由。还有如果用DDD,如何和spring比较完美的结合在一起?莫非又要回到factory的时代了。

xmuzyu
2010-05-27 19:13
2010年04月20日 11:17 "taochenpfj"的内容
.实体与值对象的区分:值对象,应该是比较好分割,我们只要把握住一点:免疫的,携带信息的无责任对象。那么对应的实体,就让我们现在比较迷惑,到底什么样的对象就应该做实体,到底什么样的实体应该做聚合根?现在的实体,从持久化层这个角度看,都是一个简 ...

说说我的想法,值对象不一定是无职责的对象。我目前判断值对象和实体的时候,主要是看是否需要跟踪,以及对象是否有独立的生命周期。如果一个对象有自己独立的生命周期,那么我觉得它就属于实体对象。

至于聚合跟的问题,我觉得这里也涉及到了封装和粒度的问题。我们涉及讲究对外封装,对内解构,当一个实体的行为变得太多的时候,我们势必要对其细粒度化,使得不同的对象负责不同的行为,但是细化以后,我们还需要封装,这就需要聚合跟了,聚合跟不仅要封装对子对象的访问,也要协调子对象来完成业务操作。

至于service等的,这其实还是与状态有关系,而我们的系统中一般存在两种状态,无状态和有状态,无状态的一般是service组件,或者一些技术性质的组件,而有状态的就是领域模型,因此这里就涉及到了生命周期管理的问题,无状态组件我们让容器管理,而领域模型需要我们自己手动管理,而我们要想管理生命周期,那么我们是必要先封装好对象的状态,因为整个生命周期中,我们所做的也就是对状态的跟踪。

猜你喜欢