domain model 的疑问

首先:我同意业务层采用domain model 优点这里不作叙述
其次:我不会采用把业务层和DAO合并(尽管那样做也有好处)
第三:我同意区分领域逻辑和业务逻辑和他们的区分规则(即持久操作不作为领域逻辑不存在于领域对象中而是作为业务逻辑存在于SERVICE中)

我的问题在于:一个逻辑的区分上.因为一个项目不会是一个人或几个人进行开发,所以开发人员的水平也是不同的,对于逻辑的区分归类上也会有不同,因为领域的区分需要一定的水平.架构师可以但架构师不可能跟踪所有的开发者.因为这样的原因使采用领域模型就会有很大的风险,如果开发人员领域对象归纳的不对或不成熟那么,架构的意义就没有了,,,,不知道有没有人注意到呢?因为看一些贴子都是关于技术的,但是一个真正的架构不仅仅是技术还有很多方面.设想一下如果框架失去了意义,那还有什么用呢?

那么有没有一种方式可以使这样的情况避免或减少出现的机会呢?

员工培训?不会吧,大哥地球人都知道了.....呵呵

谢谢

认真的问-----
架构这个词只是指技术架构么?
架构师架构师,是不是只是负责技术架构的呢?
应该是同时可以指代技术架构和业务架构吧?

楼主不要过分追求完美，如果项目够大够重要公司够有钱,找一帮牛人，你的担心自然可以小一点，但是我们有多少参与这种项目的机会呢？我们只有接受某些缺陷再总结再改进。
另外如果团队综合能力实在有限，那还是别用Domain Model的好，OO是不错，但是如果设计能力有限，设计出来的东西不好扩展不说，反而容易陷入难理解难维护的境地。架构师选择架构时也应该考虑团队的技术水平地。

我的问题之所以存在是因为系统架构师在系统架构的时候可以确定使用领域模型,领域对象中使用领域逻辑的方式,但是开发人员由于水平原因采用了贫血的领域对象,所有的逻辑都在SERVICE中,这在框架中应该如何协调呢?难道只能通过人和人之间的约定吗?

问题:  如果你采用了领域模型那么怎么样协调开发?

谢谢

如果开发人员只能写TransactionScript。那么构架师推荐DomainModel就是一个不切实际的决定。
项目能够好的运转从来都是有什么样的人，干什么样的事。理想是没用的。

构架师不放弃理想的唯一方法就是做一些构架敏感示例，以期望开发人员能够迅速领会，如果不能做到这点，放弃是唯一的选择。毕竟是在开发真实项目而不是做学院研究。

domain model已经看的太多了。。。。在team work环境下  采用大家接受度最高的构架是对project最有利的事情

这个构架也许根本无法达到让每个member都认为是最好的

也不能这么说吧, 至少走在最前面的总是少数人

一种方式就是在决定采用别人不熟悉的架构前先给他们人灌输足够的基础知识, 这个需要点时间.  项目很紧急的话，就只能采用大家最熟悉的架构了.

这个帖子沉了一段时间了，今天再看到，发现自己最近也被这个现实所困惑。

如果两个人的能力差别大一点，那么水平高的多点review给些意见，水平低点的人是很容易接受的；如果两个人水平差不多，当然都是半灌水的，那么有什么不一致的意见争论起来可真是费劲费时间，一边说要考虑扩充性，一边说别过度设计了，类似争论实在太多了；不知道真正的两大高手team work会是什么状况

我也为这个问题迷惑，所以team中有一定的层次和梯度,也有好处。