DAO如何快速适应业务变更

最近被项目给搞郁闷了,请教各位:
我所在的项目没有敏捷的开发流程,确有敏捷项目的特征。
开发过程中,需求是不断变化的,在项目开始时并不能确定需求,而是逐步给客户demo,逐步修改完成系统。客户在美国,美国那边team根据demo会随时更改domain,我所在的中国team就得不停使project各部分适应domain的更改后还能work,涉及到业务的更改,我觉得还好。可是dao层的设计,使得每次domain更改后,还要花大量人力去修改,这些修改完全就是为了同步dao和domain,使得dao能在domain更改后还能工作。这完全没有意义的工作占了我们不少时间。这其中的更改包括表结构的更改,存储过程(没有业务逻辑只操作数据),dao的实现。

简单介绍下我们dao的结构:根据domain会在oracle db里建立对应的oracle type,然后用存储过程存取操作这些oracle type,这些oracle type用jpublisher生成java class,然后自己写代码实现domain和这样的class之间的转换,这些class的对象是可以直接传给存储过程当参数的。 由此可见,我们domain更改后,要引起多少更该,虽然我们会使用反射去转换domain和与oracle type对应的class,但这些灵活性完全不够。

我潜水在jdon多时了,肯定不少人会和我一样认为,这样的项目结构绝对是有大问题的,oo的特性完全没有了,本来作为能快速适应业务更改的oo的优点现在变成了缺点。各位给点建议,有什么办法可以改善。
这里有几点我认为不能改变的现状:
1, 数据库绝对只能是oracle这样的rdbms,不可能先进到用对象数据库。(银行系统,墨守成规很重要)
2, 不使用hibernate, 以前系统是用hibernate的,因为速度和性能跟不上,才改用我上面说的dao设计。(我说服不了大家又回到or mapping上来)

难道只有code generation 这条道路了吗?
Any suggestion will be appreciated

好像发错板块了我。 晕

不用冥思苦想了,你们只有3条路可以选择:
1.提高美国方面的人员设计、分析素质,他们的业务分析太不稳定了。(这点只是从你的字面上看到的,不能确认)
2.转向ORM。不过这个也需要依靠你们团队的能力,很多时候用好Hibernate的难度也不小。
3.继续沉沦吧。

另外,如果你们处于项目的最初阶段,这样的过程是可以接受的,但是如果已经是项目的中后期对于客户的需求分析还是如此不稳定就比较可怕了。

1.提高美国方面的人员设计、分析素质,他们的业务分析太不稳定了。(这点只是从你的字面上看到的,不能确认)
------------
这点我是指望不上了,我们完全没有需求文档,甚至在项目开始的时候要做什么东西完全不清楚,us那边的team也不清楚,需求是逐步建立起来的。算这边项目的特点了。我只能想能不能通过技术手段能够让项目更加适应这种情况。

首先大概美国人也想不出优雅办法,才将这种脏活外包,所以外包之路不是那么好走的。性质和制造业一个样。

关于Model变化,这里有一个OO原则在其中,必须对变化进行分类,变化的可能频繁级别,模式就是总是假定不变和变化两个部分,所以,你们也尝试引入模式继承等设计,将一些核心模型包裹起来。

另外可以将一些边缘模型的持久化使用PropertyID和PropertyName PropertyValue这个三个字段表来表达,这样,可以动态保存大量属性类型字段,具体可见JiveJdon3的处理。

通过以上不变和变化的处理,相信能够减轻工作量,这个细化工作做得越好,你们效率就越高 。