架构中的分离

10-05-07 taochenpfj
我的一个项目中,引入了一个类似DDD的分析,然后跟兄弟们就搭手创建,实现代码!
但是,在我们创建的过程中,以及不断的分析中,我们发现全部按照ddd来实现有很多比较牵强,或者说是有点复杂化了,在此表述出来跟同行的xdjm们探讨探讨。
我们从最开始就用ddd的模式进行业务分析,找出其中的业务对象:实体、值对象、工厂、仓库、以及类似聚合根的facade对象,用来实现一个简单的表单自定义功能。这个功能里面主要是添加表单对象(形象点就是标签),然后调整这个标签的摆放位置(layout),以及这个标签的各种属性。这个过程中产生的业务就是增删改查,没有多少特别的,唉。。。。
但是我们当初在分析的时候,也是按照ddd的架构(或者说是包结构)方式来实现,增加了很多过程对象(这些对象包括ddd里面的那种分层和对象组,xdjm们可以看看那个ddd sample例子,我忘了地址了,不过在这个论坛里面有)。
等到我们真正分析业务流程的时候,我发现对上面的实现还是有些用处的,因为我们通过上面的增删改查处理过程,可以产生我们业务过程中需要的对象,在这里使用ddd就显得合理了很多。
所以,我就考虑,一个项目中的分析应该划分出两个部分进行实现:一是针对对象的维护(可能就是增删改查,不必实现ddd的那一整套);一是按照领域的业务处理,在这里面我们可以实现不同对象的管理。这里所讲的对象管理不是简单的增删改查,而是对象的初始化,数据加载等等,体现在ddd里面可能就是factory,repository等等,还有就是entity,vo,在一个业务过程里面,我们可以清楚感觉到一个对象的到底是不是有生命周期,到底是不是一个有特征的特殊对象,从而确定了实体,而我们在处理这些实体的时候就会自然而然的分离出其中的一些聚合根,如果实在找不到,我们可以用facade模式来替代,以避免产生业务泄露的缺口。
而如果我们把上面的两个方面混在一起来处理的话,我们就是在第一种情况里面产生一些迷茫,到底实体在哪里?值对象在哪里?都是增删改查,谈什么实体和值对象啊?如果是那样的话,我们就不是很清楚的分离业务处理和数据维护。。。
针对这些情况,我觉得分离增删改查相当有必要,必要到我想把增删改查用restful来实现,也就是我们的那些跟增删改查相关的页面都有统一的调用和实现机制,区别就是提交的表单,对应的数据库表,所有这些东西我们其实不必做太多工作,但是可能会有很多特例,那样就会增加相应的复杂性了。。。。
业务领域分析就是对象的协作,对象的集成。。。。这点就要具体情况具体分析了。。。。。

小弟在此抛砖引玉了。。。。

2
IceQi
2010-05-07 19:46
很实际的例子啊,但凡做过应用开发的都应该面对过这样的问题。


一是针对对象的维护
一是按照领域的业务处理

在这些划分里面数据i/o在哪里呢?在一个SQL数据库为基础的场景里面不能没有这个环节的。

感觉上lz没有真正的划分出来数据i/o和业务处理的边界,所以引发了困惑困惑。

也许是ORM/DAO的影响,我们第一感觉都是通过对象操作数据,那么维护数据就是在维护这些对象,其实不然。

在数据维护的过程中没有对象,如果使用的是关系数据库那么OO没有任何意义关注于SQL才是根本,当然现在流行于ORM但实质上还不能真正建立起来对象的环境。对象应该存在于业务过程中,只有在这个环境里面对象才有意义。

lz不妨设想一下这样的系统划分

1. 数据i/o
纯粹的数据库i/o,除了对象中数据的读写以外不考虑其他内容。这里面没有什么DDD的内容。
2. 业务过程
专注于对象生命周期的维护和使用,也不要考虑对象的数据从哪里来到哪里去。DDD


然后就是在2层之间建立接口。

[该贴被IceQi于2010-05-07 20:00修改过]

banq
2010-05-08 08:46
对象维护应该也属于对象的业务职责,CRUD看上去是对象维护,换一个角度,它实际是界面对模型发出的事件,很多业务在这个看似简单的CRUD事件中完成。比如JiveJdon是个论坛,看上去就是帖子的CRUD,实际上在这个CRUD中涉及了全部论坛业务功能。

如果你CRUD操作的模型不是领域的核心模型,那么可能会有楼主的感觉,这个我认同,但是如果CRUD的是核心模型,就恐怕无法分离了。

taochenpfj
2010-05-08 13:51
2010年05月07日 19:46 "IceQi"的内容

1. 数据i/o
纯粹的数据库i/o,除了对象中数据的读写以外不考虑其他内容。这里面没有什么DDD的内容。
2. 业务过程
专注于对象生命周期的维护和使用,也不要考虑对象的数据从哪里来到哪里去。DDD
” ...


从我说的那种情况里面,我们很难把简单的crud跟领域业务挂起钩来!

taochenpfj
2010-05-08 13:53
2010年05月08日 08:46 "banq"的内容
如果你CRUD操作的模型不是领域的核心模型,那么可能会有楼主的感觉,这个我认同,但是如果CRUD的是核心模型,就恐怕无法分离了。 ...


这个的确会有这种情况
banq老师有没有jdonjive的类图、时序图相关的设计图啊,能否借给小弟观摩观摩!?
先在此拜谢!

spell
2010-05-27 16:51
可怜的人,又被别人的概念绑架了,然后自己搞得很被动了不是。现在诟病我们的3层模式无非就是说对象贫血吗?其实是因为我们的业务没有必要搞得那么复杂,搞得那么膨胀干嘛啊,不是给自己找麻烦吗?我就觉得在现在关系数据库还是主流的年代,我们当然要用do,dao,manager,service这些东西了,本身也没有错,如果你觉得对象贫血,那你可以根据业务需求组合自己的对象,无外乎就从manager中取得domain的时候多load点记录,组合下,保存的时候在manager里面写事务,让多个dao一起操作,有那么让人讨厌吗?其实你要做一个业务就是要做那么多的事情,这个是逃不掉的,只是集中一个地方做,还是分散做,DDD在domain里面还不是要用dao去保存数据,到时候DAO要依赖domain,domain也要依赖DAO,搞得多被动啊,更难维护。找个bug要找N个对象,烦!

jackhatedance
2010-06-11 07:31
CRUD不是业务,看帖子删贴却是业务。
就好象生死不是业务,生小孩和自杀却是业务。
为什么很多人就是不懂这个道理呢。

okhaoba
2010-06-12 00:19
生死不属于人的业务,属于自然环境的业务,生小孩和自杀却是人的业务。。。。

FredWang
2010-06-13 22:35
以crud为核心的系统适合采用DDD的方式么?

猜你喜欢