没想明白:组件与领域模型是否存在冲突?

假设我们现在需要开发一个公积金管理系统，我们识别出来了：单位， 缴费人， 工资，单位公积金应该缴纳明细，个人公积金应缴纳明细，公积金账户 等对象； 然后我们把这些对象划分到不同的组件当中；比如 单位组件，缴费人组件，公积金账户组件， 然后为各个组件定义了接口，同时，也针对重用的可能性，对组建划分了层次，比如通用服务层(email等系统支持，人员管理)，专用服务层(公积金缴费人员管理)，综合业务层(人员停止缴费，计算费率等需要多个专用服务层支持的操作)。 这个过程当中，感觉破坏了面向对象的特性，因为组件的思想是一种面向服务的思想！ 而领域模型又是面向对象的思想，寻求各个对象之间的关联和操作。而组件的划分，恰恰隔离了对象之间的关联！
    谁能解此疑惑？如何建设组件与领域的和谐社会？

也许可以参考一下 <AOSD 基于用例的面向方面软件开发>

组件本来就是展示数据用的，领域模型是业务的模型，他们之间本来就不是相等的，把业务数据转化成你的组件需要的数据或者将组件中的数据转化成业务数据，这就是你的service要做的工作

中午又想了下，在一个复杂的领域当中，[Person]这个对象会和很多东西发生关联，我们不可能指望从Person就可以reference到一切。。。
所以，切分组件好像是顺理成章的。但是这么一切，综合业务逻辑组件的实现，不就成了 事务脚本 了么？ 比如

第一步获取Person
第二步获取Person的工资
第三步用计费对象计算缴费结果
xxxxx

完了，思维混乱了。

呵呵，这个问题终将成为OOP领域的永恒话题:)

目前没有完美的答案，即便是大师也给不出……

我的理解还是参考软件设计的基本原则“高内聚、低耦合”。
理论上世界万物都是有联系的，所将这种若即若离的联系都反映到对象模型中是难以想象。
因此对象模型中只反映其“高内聚”的属性和方法，而多个低耦合对象协作完成的业务逻辑则放在事物脚本中来实现。

至于对内聚、耦合的判断，那就仁者见仁智者见智了，在同一项目或产品中保持一致性尺度就可以了，不必过于较真。

而组件的划分，恰恰隔离了对象之间的关联！ 

LZ这句话是如何得到的？ 举个实例吧
不过你们将服务分层还是比较不错的做法

经过高人点拨， 想通了，和大家分享一下，和Zmud的观点基本一致：
理论上世界万物都是有联系的，但是联系有强，有弱，在OO中具体表现就是继承、关联(聚合)、依赖 等关系。组件化的目的一个是为了重用，一个是为了划分清楚组件之间的联系和职责以便于开发。划分的时候应该把握“高内聚、低耦合”的原则，比如对象之间存在“聚合”这样的关系，就应该划分在一起。相对弱的关系比如依赖、关联就可以分开放了。

为了降低组件之间的关联，保护domain，用DTO可以有效解决。

但是感觉DTO确实写起来很麻烦，直接把domain Object扔到组件之外好像又回导致较强的关联，而且基于domain object是否直接与dao关联，还要控制好事务。。。这里存在一个balance

OO设计的原则：组件内高内聚，组件间低耦合。而不是以对象的粒度。

最近也在困惑领域对象的划分问题。 如果只是单纯将系统中的业务对象当作领域对象的话感觉太窄。但是那些业务对象应该化为一个领域对象呢？

没有看明白？



领域对象的识别需要有领域的知识为基础,加上一点点地抽象归纳能力. 在分析的时候,将应用层和领域层划分出来,会比较有帮助.