分包的原则是按业务逻辑还是系统逻辑好?

是按照command,dao,daoimp等这种还是
按function1,function2等?

当系统很大是,好像两种都要用到了,大家说说一般是怎么分好?

我觉得按照功能模块比较好。

例如通用的叫做core或commons
安全部分用security，组织结构用org，发布系统用cms等等
这样，你可以很容易的把整个一部分，例如用户验证拿出来到别处用

比如著名的oscore,osuser,osworkflow等等，都是按功能

试想，把productDao和personDao放在一起，要复用还得重新打包么?

我们公司的一个系统，大块上是按照功能划分，还不错
可是，不知谁想要把web独立出来，把所有的servlet单独又分出了一个screens包
这个包里面仍然按照模块分开。
结果就是，要修改某个模块，必须打开两个地方才行。慢死了

看看《敏捷软件开发——原则、模式与实践》吧。第22章，极为精彩的论述。

楼主需要好好地理解框架、模式的概念和之间的关系。知道框架复用、设计模式复用、功能代码复用间的高低和差别后，楼主的问题也就自然而然地解决了。

还没看到那一章，回去看看，谢了

看了，有点帮助，不过还是没有解决我的问题，呵呵

我来用个例子说明吧
比如一个hrm的项目，那么实体类有Employee,Dept，用dao模式，struts框架。那么包设计为：
实体类：resoft.hrm.domain.Employee,resoft.hrm.domain.Dept
数据库访问：resoft.hrm.dao.EmployeeDao,resoft.hrm.dao.DeptDao
数据库访问实现类：resoft.hrm.dao.impl.EmployeeDaoImpl,resoft.hrm.dao.impl.DeptImpl
struts的action：resoft.hrm.web.mvc.action.AddEmployeeAction...

这种分包应该是算按系统逻辑分对吧？如果你按业务逻辑分好像麻烦很多阿
比如与部门维护的模块放在
resoft.hrm.dept包中，其中再划分为domain,dao,web.mvc，
这样不是很麻烦吗？
谁有更好的方案吗？

有意思的讨论. 我以为这类问题只会引发争论,不过意见都很中肯.
对一个问题,我个人反对持中间意见,所以即使各有优缺点,我觉得我们也应该尽量鲜明的站在一侧.
就这个问题, 我会选择按系统逻辑分, 而不按照业务逻辑.
原因呢, 我想我的出发点是很简单的: 从人的角度出发.  我想程序是由编码人员来完成的, 如果理想的话,
系统设计[偏框架,非业务]人员应该也是编码人员出身的, 在这些人的眼里, 希望看到的是一个什么结构呢,
体现在包结构上又是什么样子呢. 我知道有些程序员
看到一个类的import中导入了本类没有使用的类的话, 就不由自主的觉得不舒服[我就是一个,不是有什么病吧?],  包结构的影响我觉得比这个更大.
我总觉得, 编码人员不会去反对按业务分包, 也就是
业务的级别比框架概念要大. 但他们更希望能看到[使用]一个框架概念比业务的级别大一级的包结构.
基于5年的工作经验[编码,设计], 我不知对编码人员下这个定义是否公道?
所以,既然需要编码人员每天从早到晚的去实现一个系统, 为什么不提供一个舒服[养眼]的包结构呢, 当他们使用ide提供的树状结构视图时, 看到一个自己心目中的包结构时, 也许也会精神一些.
你们觉得呢?

BTW:
to 凤舞凰扬
在您的回复中看到了 框架复用、设计模式复用、功能代码复用. 老实说对前两个没怎么听说过, 也不知有什么内涵, 我在那里可以看到关于它们的详细介绍吗?

albert_qhd和java_archon说的正是我想要说而没说得很清楚的，呵呵

我还是要具体情况具体分析。

譬如一个很小的系统，业务功能很少，尽量分一下也不过3个，最多加上个util，但是实现是的架构又很全，层次很多，那么按功能分就很丑。这种情况我倾向于按util分。

但是系统又是业务功能很多了，单纯按系统功能分分的话，action，dao每个包里面的类也会很多，那时也丑了。

那么一个大的系统，我就是倾向于两种结合了，但是这样又冗余了，也丑。petstore用的就是这种方式，先业务后系统。

那么有没有比较好的结合方式呢？有种方式高级一点，奇怪一点。就是按业务功能分文件夹，按逻辑功能分包，利用JAVA包机制中可以多个Source根目录的功能，实现逻辑上面是同一个包，物理上按业务功能分开，在Eclipse和Jbuilder都可以体现出来的。好像叫什么“文件夹映射”功能。这个用在把测试用例和被测试类分开目录而无需import方面，可能大家知道比较多。adventrue用的就是这种方式。

这种方式在我看来是最好了，只是比较麻烦，稍微有难度。

看看hibernate吧，它是纯粹按照业务功能分的，基本只有一层，第一层有十几个目录，呵呵.


最近看到个MMBase，有点体会，感觉或者这样：

下面有个core，系统核心底层的，按系统功能分包；
上面有个modules，业务逻辑的，按业务逻辑分包，action就分散其中了


感觉这样也挺好的，大家认为呢？

to:andyyehoo
看来你还是没有仔细看《敏捷软件开发》，按照那本书的思想，如何分包是完全可以通过java类的相关性推导出来的。也就是，有可能（也许已经有了）做出这样的插件，比如说在eclipse上，运行一下，就能自动分包了。