看dddsample 实例 后的个人理解
感谢banq,这几天一直在研究dddsample 实例代码,结合目前项目正在使用的开发框架写点理解心得:
先说一下目前我们项目框架也是三层结构(见下图):
显示层:struts配置文件(jsp,js,action,actionform)
业务层:spring配置文件(service,vo)
持久层:spring,hibernate配置文件(dao,po)
在业务层里存放的对象有业务服务对象(Service)和业务值对象(VO),在Service里控制业务逻辑或业务规则,同时管理业务一致性(控制事务),在持久层里控制业务值对象持久化及查询服务(即业务数据的增删改查),层之间有明确的职责划分。
可能上面框架也是国内公司基本采用的模式,下面再结合DDD领域设计及dddsample 代码的风格谈一下自己的理解
1) DDD对领域层有了特别关注,站在业务领域的角度分析和设计领域对象及对象之间的关系,领域对象反映了现实业务领域的真实场景,加上聚合,工厂模式更能应对今后业务的变更或发展
反观我们目前的框架,没有从整体的业务领域来构思对象,大多都是单表PO,VO在操作,PO主要是为了快速持久化,VO主要是为了传递业务数据,而VO的聚合对象都靠程序来管理(如根据主PO再查询关联从PO集,在转换成从VO,设置到主VO里),也就是VO很大部分作用都是为了显示层来服务,显示什么数据就构造什么属性的VO。
认识:领域对象可供整个业务领域复用,但我们框架的VO基本无法复用(因为它是因显示层来构造)
2)DDD中应用层和领域层分开,应用层控制业务界面操作的事务一致性,根据界面操作调度业务逻辑并给用户输出显示结果,领域层显示领域内的业务数据及数据转换规则。应用层是转为显示层服务的,所以不可复用;而领域层是可供多个应用层进而为多个显示层服务。
反观我们目前框架,中间只有一个业务层,里面夹杂着业务服务,有的是显示层服务方法,有的是业务规则判定供业务复用公共方法,所以既有对显示层专有不可共享的方法,又有其他业务共享的方法;这样在实际使用过程中会很难管理(比如业务发生变化后,有些被共享的业务层方法会随业务变更进行调整,但因为已被复用,所以经常会改造,出现多个相似作用的方法)
认识:稳定的领域层是可被共享的,但我们框架的业务层只有一层很难稳定,业务无法有效共享;
看代码理解的最大困难:
1)领域仓库CargoRepository 和基础实施层的仓库实现CargoRepositoryHibernate,分别属于两个层;这与我头脑中的一贯思维不符,一直想着CargoRepository 接口和实现应该在一个层里。因为interfaces和 application 下的接口和实现都在一个层里,如过他们在一个层里那我理解会舒服点(也即领域对象是属于领域层,但领域层的获取属于基础实施层)。。。。。
2)代码中的包结构,按我正常理解应该以业务来组织,如booking/application,domain,infrastructure,interfaces;
[该贴被agilestone于2009-10-21 18:39修改过]