实践ddd,太让人沮丧了。。

12-02-17 berserk
现在很沮丧啊。。。

前段时间负责的项目,雄赳赳的采用领域对象的方式来建模和编写。

将系统分成: controller > 粗粒度service > context > repository > dao 这几层来进行开发,

同时,借鉴 dci的架构 将bo的行为移到了role中。同时对bo进行了缓存。

本来觉得挺好的,但在实践中,

却遇到了不少问题:

原有系统架构下的缓存在集群下同步问题,

开发方式改变的不适应问题。

除了这些客观的原因。

更致命的是,由于是第一次尝试,经验不足,不能很好的分离领域对象,和它们之间的关系!

很多时候不知不觉就使用了原来的开发方式,

比如,

一个repository,写着写着就成了dao。。。

一个service,写着写着就把role,context的事做了。。

一个bo,写着写着,不知道该咋维护它的状态了,哪里都担心出问题,没有使用db那么踏实。

很多时候不知道怎么用领域设计的思路来抉择,

比如,

记录的分页查询,是直接使用dao呢,还是组装bo?

往前台发送的数据应不应该是bo?

bo太过重量级,它里面的每个关联对象是不是该使用懒加载方式呢,但这样会不会让bo的代码很冗余?

bo的状态该怎么维护呢。。。

等等,这段时间头都大了,不停的修改代码,但系统功能开发并没有多大进展。。

距离代码打包期越来越近,人也越来越焦虑,时时有使用原来的 controller > service > dao开发方式几下子搞定的冲动。。

ddd 远看很美好,实践起来很困难。。。唉, 沮丧的很。。。

17
banq
2012-02-18 10:07
2012年02月17日 20:30 "@berserk"的内容
一个repository,写着写着就成了dao。。。

一个service,写着写着就把role,context的事做了。。

一个bo,写着写着,不知道该咋维护它的状态了,哪里都担心出问题,没有使用db那么踏实。 ...

如果说DDD只是指引了一个OO方向,那么当你走上面向对象道路时,还需要更多OO战术知识和技巧来实施。

实施DDD,CQRS读写分离是必须的架构,事件驱动是缺少不了的,我当初开发JiveJdon也曾经碰到过你这样的问题,你可以从JiveJdon 4以前的版本看到这个问题,后来在Jdonframework引入事件驱动后,才更好地将BO也就是领域对象和Service等等隔离开。

这之中经历最大的开发方式转变就是:从过去Service+数据库为主的驱动方式,也就是行为用Service,状态用数据库,这种方式相当普遍,坏处在其他帖子已经谈到了,但是搞了几年这种方式,已经习惯了,改为由领域对象统管封装行为和状态(原来是分散的),就象一群孩子平时野惯了,没有人管,现在多了一个领域对象BO来封装统管,要么管得太死,成了一个大BO死BO,要么管不住,本来属于同一业务逻辑的行为和状态还是分散开来。

当初我用DDD开发JiveJdon时,也曾经遇到这个问题,属于孤独无援,还好是开源,大不了废了,在经历几乎失败之后,你才能发现柳暗花明,自身修行上了一个新阶段。

[该贴被banq于2012-02-18 10:12修改过]

lwwcl1314
2012-02-19 12:42
最近一个项目也想尝试DDD,最后种种原因用回了Bo+dao的模式。个人想自己弄弄实践下,再在公司中使用。

Lz,还是慢慢消化下,至少会慢慢理解DDD的,只要事情做了,总比没有做好。

berserk
2012-02-20 18:50
在实际过程中,我有几个问题一直没想得好。

第一:ddd的最大好处是提炼了bo和相关的行为,使系统代码设计不是以前台命令驱动,而是还原领域中的各种概念。

这样就有一个问题了,如果,我对某个重要bo的理解有误了,并且直到系统开发接近尾声时才发现,不得不进行修改,由于系统不是使用原来的简单层次结构开发模式,因此,充血的bo与其他场景,bo实质的产生了不少行为交互,实质上是代码产生了多处耦合的情况。这样,当我修改这个bo时,很容易牵一发,动全身。

在实践里,我就经常遇到这个问题,对oo抽象不到位,导致修改bo,与之关联的很多代码都需要修改了。。。而不是原来的直接写个service解决一切,出问题也只修改部分地方,虽然这个几部分的代码没多少可读性。。

第二:bo必须存入缓存,ddd才能有效率可言吗?开发中,bo的创建代价很大,因为它有很多关联对象需要取查询。同时,bo的状态随时在变,如果随时都去连db,效率可想而知。

按照原来贫血模型的方式,查询一个实体的代价是不大的,因为实体只相当于一个vo,没有很多关联。因此,我可以不去怎么关注实体是否需要缓存起来,(系统大了之后,db holde不住,这个问题也逐渐暴露了。。)

在实践过程中,显示列表这种操作总让我心惊胆颤,因为,这意味着让我得去查询一堆bo。。。

cqrs的架构,我不是很了解,但它能解决我这个问题吗?

第三:实践中的协作开发,不知道该如何划分职责,ddd能提高协作开发的效率吗?

按照原来以前台命令驱动的设计方式,很大程度上让各自的开发过程隔离了,虽然每个人可能重复实现了某个公共业务,可能整个系统代码设计能体现出来的业务逻辑比较支离破碎。但由于隔离了开发过程,多人能够并行开发,因此它确实提高了开发效率。

但用ddd的方式,某个bo可能会横跨整个系统,某个业务需要多个bo协同完成。。

但实际上,开发人员不可能同时都写好这些bo,总是遇到,这个等那个,那个等这个的问题。 在我实践ddd的期间,调整了多次开发分工:按模块分工、按接口分工、前、后台页面分离开发。。。但效果不是很好。。。我很想知道,使用ddd的情况下,多人协同开发时,该如何分工。。。或是我该去看看xp?

上面这几个问题,望解答。。

12031347
2012-02-21 12:40
强烈关注,个人目前还没有完整经历过DDD驱动开发,个人只是在业务分析整理过程中会使用这种思想去抽象去总结,实际的开发过程并没有采用这种模式,仍然是采用脚本模式来做的。

猜你喜欢
4Go 1 2 3 4 下一页