发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 大数据 扩展性 并发编程 事件驱动 分布式 SOA
1 2 下一页 Go 2

关于ddd+up+tdd的困惑!

         
2008-07-16 01:10
赞助商链接

最近一段时间都在看ddd和up,个人感觉使用up进行项目的管理开发,运用ddd进行领域建模,在设计阶段,运用tdd进行驱动开发,这应该是一个比较理想的开发模式,但好的东西在项目的开发中不一定会得到充分的运用。

比如up中强调的迭代开发,细化阶段经过5-8次迭代,每次迭代3周,要完成确定整体需求的90%,完成20%左右的成品代码的编写,项目风险最高、最核心的业务的需求和设计已经确定并有部分实现,剩下的在构造和移交阶段去完成。每次一迭代中又是按照ddd进行领域驱动建模,通过tdd来测试驱动开发。但是在实际开发中,很多情况是客户并不知道他需要什么,需求十分模糊,甚至只有不到一百个字的需求,需求的不断深化和挖掘需要大量的沟通和时间,而这一点首先是客户不一定做到,在客户的传统思想中,你先拿出一个整体方案看看再说,也就是系统的需求分析文档,有了需求分析文档,再看看你的概要设计,等详细设计出来后,才给你打钱。客户需求的挖掘和up强调的迭代开发是吻合的,而客户的思维是见着东西才给钱又和迭代开发的每次迭代出一个可运行的产品相矛盾,因为客户没有更多的耐心,等你一点一点去捏泥人。我记得在一本国外大师写的书中提到过盖房子的故事,一个公司选两家设计公司给他们设计房子,第一家公司一去就拿来之前才做好的一个非常不错的建设方案,有成品、有图纸,看上去效果也不错;另一家公司没有给出图纸,也没有太多承诺,它要求看客户的建设场地和需求,根据客户的需求重新量身定做一套设计方案,确保设计出来的东西就是客户想要的东西。这位大师强调说,最后取胜的一定是后面一家公司,因为他把需求放到了第一位,相对而言风险更低,成功的机会更大,前一家公司虽然有一个不错的设计方案,而且有成品展示,但是别人认为好的东西,客户不一定就认为好,用在别处成功的东西,用在这里不一定就一样会成功,所以从这点考虑,这家公司必败无疑。

我很赞同这位大师的观点,但是在国内,似乎很多公司都会选择第一家公司为自己做设计,因为他们往往没有自己的明确的需求,很多时候很容易被一些先入为主的观念所左右,所以大多数情况下,他们很轻易的相信他们所看见的,而不一定是仔细考虑他们真正想要什么,这是一个十分突出的问题!

其次,迭代开发对团队的要求很高,它需要团队成员对涉及的领域知识十分熟悉,甚至是精通领域概念,这样才能在每次迭代中做到游刃有余,而这一点上有很多公司也是望而却步,他们常常会说:这东西看上去不错,但是我们不会去用!

再次,说一个具体的问题。就是对象和关系不匹配的问题,在设计领域模型的时候,我们从面向对象的角度去分析实体、值对象,分析关联,隔离领域、确定聚合,随着对领域的不断深入理解,我们会去不断的精华模型,去改善设计,是设计更加柔性,使结构更加合理。但在对象的持久化的问题上,很多时候我们不愿意去使用hiberante这样的ormapping工具,担心hibernate在某些方面(比如性能上),不如原生sql来得高效,多数情况是使用自己开发的中间件,对jdbc进行封装,对分布式数据进行一些处理,这个时候关系模型的设计显得越发的重要,有部分重要的业务甚至放到了数据库中去存储过程实现。关系模型和对象模型在粒度上不同,导致不匹配的问题比比皆是,最终选择了一个折中的方案,看上去成了一个类一张表的样子,在使用对象的时候,对象的导航也成了一件代价巨大的事情,因为没有了hibernate这样的ormapping工具,使得从数据库中查询来的数据无法自动封装成对象,这样对象模型中的对象导航就成了一副空架子,设计的时候虽然是面向对象的东西,但真正实现起来有逐渐回到了面向过程的老路上来,这种感觉十分痛苦!

如何解决上述存在的问题呢,这是最近一直困扰我的问题,请大伙谈谈自己的看法!

2008-07-16 17:16

>对象的导航也成了一件代价巨大的事情,因为没有了Hibernate这样的ormapping工具,
是否使用ORM框架倒是其次,有了就是开发方便提高效率,但是必须明确持久化只是对象冬眠暂时休息的
一种行为,是众多业务行为中一种通用特殊行为,这句话道理很简单,但是要转变过来很不容易的。
使用持久层技术ORM或自己的框架,严格分割领域对象业务和领域对象冬眠持久化之间的界线,不要因为
熟悉SQL,就认为使用SQl或存储过程实现业务更快,一定要告诉自己:这是先入为主的原因,自己要探索
一条针对当前这个项目的复杂Domian Model之路。

不用太担心性能,如果你真的关注对象式系统的性能,就应该引入缓存,这时你花费的力气会让你明白,不如直接使用ORM。

2008-07-17 00:10

>但是必须明确持久化只是对象冬眠暂时休息的一种行为,是众多业务行为中一种通用特殊行为
这句话似懂非懂,需要好好体会,banq能否在深入的谈谈

2008-07-18 12:56

不错的问题,希望banq能够深入谈谈看法..

2008-07-18 16:19

>但是必须明确持久化只是对象冬眠暂时休息的一种行为,是众多业务行为中一种通用特殊行为

我的意思是:领域对象有很多重要本质的业务行为,不只是持久化,但是我们经常将持久化作为一个唯一依赖的行为,通过这个行为管道变相的实现很多业务功能。

见图中,一个正常的领域模型,有着丰富的各种不同业务操作,严格来说:持久化并不是业务行为,我们去问一个不懂计算机的业务人员,他的业务模型是否需要持久化,他肯定不知所云,持久化只是我们计算机人员为避免数据因为关机丢失或事务一致等原因设立的一个技术概念。

但是我们很多软件人员就死死抱住持久化这一所谓技术法宝,通过这一个唯一管道,再注入SQL这样数学式抽象表达方式,变态地实现各种模型业务行为。打个比喻:开车有5档,不同情况使用不同档,但是如果一直只使用一档开车,可不可以?可以,但这是扭曲的;再比喻:人有两只手,如果你做什么都使用其中一只手;可不可以?可以,但是这是扭曲的;业务模型有各种业务行为,你只通过其中一个通用的持久化行为实现本应该和持久化并行的其他业务行为?可不可以?可以,但这是扭曲的。

所以,我说:数据库思维和方式害了我们,影响我们正常自然的开发,OO就是自然正常开发,我们今天叫它为
OO,明天称为其DDD,后天可能又是一种称谓,不要因为它有一个称谓,就玩名词逻辑,什么OO不是万能等等,
说这话的人老子道德经开篇“名可名,非常名”可能都没有读过,名称只是名称而已。

恕我直言,楼主虽然使用DDD,但是不彻底,掺杂了关系模型,这两个是矛盾的,是水和火,前些时候也看到有人在Jdon鼓吹SQL和DDD两个都要,两个都要就是你这样的后果,所以,不从本质思维深处认识到对象和关系的不匹配,以为那只是理论上矛盾,那么实际中你将因为这个不匹配白白付出汗水和项目的失败,这些都是刻骨铭心的,这种失败的打击心情是那些纸上谈兵者所无法体谅的。

所以,楼主这种情况必须在DDD上深入,完全去除关系模型,恢复业务模型的常态,其实衡量一个领域模型是否
正常,只要让不懂计算机和数据库的业务人员看看,如果他们能够看懂,说明你的业务模型比较全面且没有关系数据库概念。





2Go 1 2 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com