领域模型到底怎么做？

看了论坛上很多的关于领域模型的帖子，总有个疑惑，很难解决。
因为设计领域对象肯定是从需求出发，一般来说需求中对于一些比较大的数据集，总会有一些分页方面的需求。
比如，一个论坛中会有很多的帖子，而常见的显示方式都是分页的。
那如果应用领域模型，这个Forum对象该如何设计呢？

class Forum {
    // field
    private List posts;
    // property 这个甚至可以不要。
    public List getPost(); {...};
    // business method
    public List getPosts(int page, int pageSize); {...};
}

这个应该是一个比较正常的设计，其中getPosts(int page, int pageSize )是根据需求设计的。
但是如果从性能上来考虑，那这个getPosts必须知道数据访问对象,也就是说，在getPosts(int page, int pageSize)里必须有调用DAO中方法的代码。
我的思路，是

class Forum {

    public List getPosts(int page, int pageSize); {
         PostDAO dao = Post.getDAO();;
         return dao.findPosts(page, pageSize);;
    }
}

但是，把DAO代码放进业务方法里总感觉别扭，但是不这么写的话，性能方面或者OO方面很难平衡:
一种方法是取出所有的posts,然后用Java代码分页；

    public List getPosts(int page, int pageSize); {
        // TODO 考虑是否创建PostDAO,并且直接分页查询
     // 利:更加体现对象关系,提高应用程序性能
     // 弊:业务逻辑必须操作数据代码

     // 使用Java代码分页
        List list = new ArrayList(pageSize);;
        int offset = (page-1);*pageSize;
        if (offset < ads.size();); {
	        Iterator li = ads.listIterator(offset);;
	        long i = 0;
	        while (li.hasNext(); && (i++ < pageSize);); {
	            list.add(li.next(););;
	        }
        }
        return list;
    }

还有一种就是在Service里根据Forum对象,调用PostDAO把所有该Forum的posts取出来

postDAO.findPosts(forum,page,pageSize);。

另外，在复杂点的应用中如果，要用到Transaction的话，这些beginTransaction,commit,rollback的代码又要写在哪里呢？是在这个Business Method里，还是外面，都是各难题。
所以现在一直很头疼，碰到这种情况到底该如何平衡。[/list]

首先楼上混淆了两点点，就是架构中对象访问的分层与系统的业务分层的混乱。我们常说的DAO，Business Tile以及Transaction的处理位置，这些都是和架构中的分层有关系，并不太牵扯到楼上所谓领域模型（我不太清楚这个领域模型是哪里来的概念，有些陌生）的设计。其次，建模和设计实现是两码事，我估计楼主是想问怎么进行领域模型的设计与实现吧？
    一般在做分析的时候，存在两种分析，一就是基于用例的分析和设计（一般来说用例是描述业务需求而比较少关系系统环境需求），它精化的是对用例的分解和实现，或者简单地讲，它只能描述出实现用例所需的基本类图，序列/协作图和活动/状态图，而无法去分析设计整体架构的关系图。另外一种分析也就是架构设计了（它更多地关心在系统环境以及用户独特需求下系统的结构关系），它就负责描述我们常说的层，描述component图等。
    在RUP中，虽然分析后部分的一切的导入都是基于用例，其实是存在两条分析线的。所以在一个比较完善的团队中，SA是有两个以上，并分成两个方向，一个趋向于BA，有很好的分析能力或者业务领域的知识，他们主要完成业务建模与需求分；，而一个趋向于技术，也就是系统设计员，有很好的技术功底，他们主要完成系统建模和架构设计。两者再往后发展，也就是非常紧俏的业务分析咨询师和架构设计师了，呵呵，能达到以上境界的，屈指可数了。
    其实在我们这里讨论的比较优秀的网友大多是趋向与后者的。

这两句话我怎么没看懂，业务对象中调用Dao接口不就是业务曾在调用Dao层么，层与层之间是接口通信的，晕

可能应该说业务层不要依赖于DAO。
不过，按照PoEAA里的Domain Model,他的Business Methods也是会调用数据访问对象的，每个Domain Model都有自己的数据保持器。

业务层就是依赖持久层的呀，双方通信的接口是Dao.

明摆着的阿，不要依赖，就是不要依赖于具体的实现阿，比如JDBC，比如Hibernate
现在的问题是到底应该不应该在业务对象的业务方法中调用DAO中的方法来按条件查询数据，比如得到符合某些条件与其关联的对象的数据。