1：在现在常用的service \ dao 包结构中.子系统如果划分为类似的包XX.service.a XX.service.b XX.service.C 为三个子系统的service部分是接口 用把接口都分别放在各自的子系统包结构下吗？如果子系统中还分模块就会有XX.service.a.X
XX.service.a.Y
是不是应该把接口都放在子系统一个包中，就不用各自放在自己的模块中？因为接口只起到对下层实现隐藏细节的作用。
2：四色图中MI粉色部分与粉色部分的聚合是否代表service的注入那？比如一个MI与另外两MI之间是聚合关系，是否说明另外两个服务被注入到一个服务中那？
为什么没有人回答那？
注意Service只是一个外表的东西，不应该将业务核心放在service包下面，甚至建立子包，业务核心按照DDD来划分为领域层和服务层，大部分业务核心在Domain Model包下面，service只是供外界调用的简单几个接口和实现罢了。
如果你试图在service包下面深挖洞，广积粮，那么你可能没有完全理解DDD。
参看JiveJdon3的service设计。
>四色图中MI粉色部分与粉色部分的聚合
不是叫聚合，叫依赖，标识MI的依赖关系。
[该贴被banq于2007年03月06日 10:12修改过]
我知道你说的是model或称其为domain的那一层核心业务实体。我现在也在用只不过用其存储数据没有相应的逻辑。具体的业务逻辑都写在service层的实现里面了。现在我只是不知道划分包结构意义是否正确，现在的做法什么3个子系统每个都有一套结构比如model.A Action.A Service.A Dao.A 这是A子系统，其下还有Service.A.a (子模块)不知道您有什么建议。
jdon3我有看过 你也是service为接口 其下有四个service的实现包分别是imp imp.account imp.message imp.upload 这就是我所说的子模块。实现类中不就是业务逻辑吗 比如找到论坛消息 而这里面也依赖了model中的论坛消息。这我都可以理解。我要说的是你这只是一个系统。论坛系统。如果我是一个很大的系统包括几个子系统就如你那jdon3是否service可分为三个子系统的包结构 如 service.fourm
service.wiki service.blogs 类似以上这三个
>如果我是一个很大的系统包括几个子系统就如你那jdon3是否service可分为三个子>系统的包结构 如 service.fourmservice.wiki service.blogs 类似以上这三个
如果是一个很大的系统，从归类原则包是应该分为service.fourmservice.wiki service.blogs这几个子包，但是事情不能只从Service出发，按照DDD，Domain Model是核心，起基本决定作用，因此service是围绕Domain Model的，我的经验是：通常一个实体Model对应一个service,service分类是取决于Model的，否则，不能围绕Domain Model分类，Service就难于管理和维护。
可以想像将Service看成Model的一个行为接口，以前MF曾经指责这种Model为贫血模型或者失血模型，现在有了Evans DDD，我们可以完整的理解胖模型的概念了，而且DDD对SOA的实现提供了理论分析支持，这些都是绕口舌的东西，可以不管它，但是必须注意的就是：service只是一个行为性质接口，不要将其做复杂，否则过去误用无态EJB那样导致过程化编程，业务核心是应该在Domain Model，而不是在service,知易行难，所以也是我不主张在service深挖洞的原因。
个人意见，欢迎探讨。