原创作者: guyuanwuxin
阅读:1050次
评论:0条
更新时间:2011-05-26
首先:我同意业务层采用domain model 优点这里不作叙述
其次:我不会采用把业务层和DAO合并(尽管那样做也有好处)
第三:我同意区分领域逻辑和业务逻辑和他们的区分规则(即持久操作不作为领域逻辑不存在于领域对象中而是作为业务逻辑存在于SERVICE中)
我的问题在于:一个逻辑的区分上.因为一个项目不会是一个人或几个人进行开发,所以开发人员的水平也是不同的,对于逻辑的区分归类上也会有不同,因为领域的区分需要一定的水平.架构师可以但架构师不可能跟踪所有的开发者.因为这样的原因使采用领域模型就会有很大的风险,如果开发人员领域对象归纳的不对或不成熟那么,架构的意义就没有了,,,,不知道有没有人注意到呢?因为看一些贴子都是关于技术的,但是一个真正的架构不仅仅是技术还有很多方面.设想一下如果框架失去了意义,那还有什么用呢?
那么有没有一种方式可以使这样的情况避免或减少出现的机会呢?
员工培训?不会吧,大哥地球人都知道了.....呵呵
谢谢
其次:我不会采用把业务层和DAO合并(尽管那样做也有好处)
第三:我同意区分领域逻辑和业务逻辑和他们的区分规则(即持久操作不作为领域逻辑不存在于领域对象中而是作为业务逻辑存在于SERVICE中)
我的问题在于:一个逻辑的区分上.因为一个项目不会是一个人或几个人进行开发,所以开发人员的水平也是不同的,对于逻辑的区分归类上也会有不同,因为领域的区分需要一定的水平.架构师可以但架构师不可能跟踪所有的开发者.因为这样的原因使采用领域模型就会有很大的风险,如果开发人员领域对象归纳的不对或不成熟那么,架构的意义就没有了,,,,不知道有没有人注意到呢?因为看一些贴子都是关于技术的,但是一个真正的架构不仅仅是技术还有很多方面.设想一下如果框架失去了意义,那还有什么用呢?
那么有没有一种方式可以使这样的情况避免或减少出现的机会呢?
员工培训?不会吧,大哥地球人都知道了.....呵呵
谢谢
评论 共 0 条 请登录后发表评论