请教关于domain对象注入service

dmain.startTransaction();
dmain.dosomthing();
dmain.getFoo(foo);
dmain.endTransaction();

这样子写代码是不是有点傻?

为何要这样做？目的只有一个，做出一个可以维护的系统。好，这是我们的目的。那么我们到底怎么样去设计它，现在是我们的难题。LZ提这个问题，似乎也有点不太清楚服务层为什么需要这样做。（原因很多，分层，封装上下边界，之后在服务层内直接调用类似于API的操作 …… ……）

其实很简单啊：
LZ，你的领域逻辑是哪些？你的技术逻辑又是哪些？好，先搞清楚PAY这个操作到底属于什么。
为什么要这样设计，在服务层里直接调用DAO层的操作，目前来说DAO的设计是否合理？等等。没有DAO，不知道项目的大小和领域复杂度，光靠一个服务层基本上不能断定你的这个设计是好是坏。

大三小菜鸟。有错别把我批的太惨就行，呵呵！

DMAIN里实现了这些操作？还是引用了别的层的方法？

引用加继承
本想把代码改成这个样子.
连接池是单实例的.......

但看看也非常恶心所以就不来了.

厄。。。。Java 的 DDD 讨论还在持续啊－ －，请 LZ 参看 从大概 05 年至今在 JavaEye 上的相关讨论，你就可以找到你问题的答案了 :-)

我觉得很多时候pay不是user的行为，你究竟是pay什么呢？pay bill,pay order还是pay 什么其他呢？如果让我去考虑一个问题，我会先确定实体类，一开始是数据和行为结合起来的，关注于实体类的时候，先不考虑数据库，因为那个session state和persistent state的同步问题是和技术相关的（甚至用后台进程来同步）。确定职责通常都是谁有数据，谁处理。倘若这时候应用比较复杂，可能这样做会导致某些类过于大，或者层次结构过多，这时候才会考虑其他的策略，然后把某些行为代理出去或者把数据和行为分开。到最后这个职责分配给了谁？是看系统的复杂度的。但是起点都是，谁有数据，谁处理。只不过由于要综合权衡可重用性，易用性等等因素，一个原来简单的设计慢慢演化到后面变成复杂的设计，这种设计的推进导致某些职责被分配出原来那个拥有数据的类。而不会一开始设计就已经定死了pay有个pay service，专门做pay，一开始的设计怎么会知道为什么会有这个类呢？不看实际情况就按着某些分层的做法来套，往往会导致复杂度过高，而且不值得这么做。到最后由于增加了复杂度，导致晕头转向，都不知道职责怎么分配了(还怎么分而治之呢)。

其实为什么要引入Service呢？本身就必须看实际的情况。可能为了易用性，隐藏细节等等（facade,adapter），有时加一个中间层可以起到facade的作用，这种通常是application service，而对于domain service多数是分配职责的时候，找不到一个合适的实体类，才虚拟一个无状态的service出来，把职责分配给这个service,而你可以不命名为什么service。楼主这里的问题是，pay怎么是user的方法，同时又是pay service的方法呢？而你这里只是把它代理出去，难道有user的pay和没有user的pay不一样？如果pay需要调用user的数据，可以考虑把user作为参数传给pay(user)。
我个人是倾向充血的，是否好的设计只能够在实际问题当中考虑，设计本来就是循序渐进的演化，而不是一开始就定死的，所以随便就说这样耦合性增大，明显是没有理由的。不好 控制 取决于你切分边界的好坏。
本来就没有silver bullet，我只是发表一下看法。请 高手 指教。

建议楼主看看之前论坛讨论过的domainmodel的相关帖子，我觉得楼主所说的就像贫血和充血的问题，domain object和domain logic的问题。

这种事情还是少做为好，不给自己惹麻烦是其次，更重要的是不要给别人惹麻烦