对于这种数据库类型的程序我赞成分模块开发，不过需要有架构设计、总体设计和数据库设计的统一，每个模块的详细设计可以分模块进行。

像我们这样的小公司，整个公司只有一到两个技术员，什么分层不分层，什么模块不模块，从数据库到业务逻辑，从需求分析到系统分析，从进度控制到代码测试，从编写代码到系统实施，从业务谈判到协调客户，从安全性的考虑到可伸缩性的考虑，从asp到.net，从t-sql到xml，从flash到photo shop，从CSS到xml，从流媒体到多媒体，从修复硬盘0磁道损坏到配置路由器，从设置防火墙策略到配置VPN，从布线到配置ftp,mail服务器,从设置虚拟主机到服务器上架......，这些差不多都是一个人去做的，公司也没有主线，公司接什么业务你就去做什么工作，真羡慕博客园上这些老大们一个礼拜上五天班，又有三险一金，而且做着比较有技术含量的工作，我们这些小公司员工都不知道出路在哪里，今天光赤光赤弄一顿.net，明天光赤光赤去电信机房去修服务器了，今天要把一大厚本的资料扫成电子版本，明天就可能就要给客户改个flash，我汗死，，，

到现在偶都不知道一个程序怎么算是一层，怎么算是一个模块，一切偶一个人说了算，说他是一个模块他就是一个模块，说他是一个层他就是一个层。不过个人还是赞成按模块来开发的，当然了，个别比较专业的东西需要单独拿出来让人做，比如说要数据服务层编写一个比较复杂的T-SQL的存储过程，这也许需要一些专业的数据库开发人员去做，让一个不熟悉的人做他还需要看联机文档并且需要2倍甚至更多的时间去完成。

当然了，也有一些专业人员比较喜欢单一的工作，不愿意天天去面临不同的困难，他就擅长开发asp.net，也就设计设计界面，他就喜欢负责做UI比较好，因为他已经熟练的不能在熟练了，做出的UI无论在感官上还是易用性上都比别人做的好，客户认可度比较高，而且做的快，那他就别管业务逻辑和数据库设计了，负责表示层就行，而且应该给他高工资，对他来说没有技术含量，但是对公司来说他能在最短时间内做最多的事情。

你这样处理的话，大量重复的代码出现是不可避免了，而且可能会在项目组成员中出现重复性的劳动

如果有成熟的框架结构，也就是通用的底层，我认为分模块不但可以避免责任的推卸，分工的明确，而且还能在很大程度上做到代码的复用。当然了，前提是要有一个套成熟的框架，有一个框架维护的“高工”.目前我们公司就具备这条件，按分模块开发，感觉效果还不错,hoho!

只要沟通到位，系统框架设计到位。这种类型的系统我还是觉得应该用模块化的思路做。我目前在给某电信部门做oa，用的就是模块化的思路。不过我们需要交叉时，都会问问对方一些情况，而且写的方法，类都有注解，一般看了都明白。语法，命名也尽可能统一。

你的图画的很好，一目了然，呵呵

就我的经验来看，在写业务逻辑的时候，最害怕的就是数据层的变动。而数据层中的表和表与表之间的逻辑关系是一个有机的整体，也有其相对独立的设计方法，与业务逻辑层的架构设计还是有区别的。很多时候逻辑层和界面层的工作量不允许每层一个人，这时候层内分工当然也要做，这时候分工自然就是按照功能模块来划分的了。

但是数据层内部可就没有那么清晰的模块界线了，至少不一定与逻辑层和界面层的模块界线一样。所以我的意见是你图中纵向的分工界线别一下子划到底，而是画到数据层上面就止住，如果用我的话说，那就是“五花肉”别一刀全切开，而是剩最下面的瘦肉别动。

最下面的数据层还是交给专门的数据库设计人员来负责比较好，也不一定是一个人，他们在数据层内的分工应该不是按照模块来划分的。

分工合作是人与人之间的交流问题，不完全是技术问题。用技术头脑去解决人的问题，只能越解决越麻烦。
如果你的项目组中有一个对构架设计比较有能力的人，同时对管理也有一定的能力，应该把所有的设计和代码都交给他管，其余的程序员都是他的助手。项目经理就可以多管管需求、设计和测试。
如果这个人对技术很在行，但是没有什么管理经验，就让他搭建一个代码框架，估算一下工作量，然后项目经理分配工作，监督进度。同时让这个高手负责解答疑问、解决框架中的bug、必要的时候改进这个框架。
要是没有这样的人，唯一的办法就是大量的开会，花时间讲需求，讲设计，code review。
如果有人推脱责任，这不是技术问题，这是态度问题，沟通问题，或者是他对自己的工作范围认识错误。

怎么高兴怎么好

感觉项目的基础部分还是要进行规范的设计，进行各个层面的评审。如果构架出来了，高层设计也基本成型，那么分开五花肉也应该是没有问题的。感觉作者面对的系统是一个无法扩展的系统，每增加一个需求都要影响到系统底层，这也是无奈之举。

作坊生产和工厂化生产的区别
没有谁对谁错 关键看生产环境,因地制宜 适当的时候运用适当的设计模式

http://tansm.cnblogs.com/archive/2005/10/06/249378.aspx

提到了横向分工和纵向分工。和一位同事提到的层次分工或者模块分工类似。

以我看，这种划分方式都有些僵化，都是假设你分的是一个平面的东西。

要知道只有平面的才有仅仅考虑横向，纵向。

如果是三维的呢？是否要考虑入纸方向？

软件可不仅仅三维那么简单。接口才是真的分工方式。通过良好的设计达到对用户，对同事的模块，对硬件等外部明确的接口，就可以划分自己的一亩三分地，责任才会明确。

把接口搞清础，把一个不具备形态，外观的软件变成一个可划分的东西，不容易。而横向分工和纵向分工虽然简单，倒是比较直接一些。

最重要的是以不变应万变这点最难,你接口设计得再好,人家要改,说不好这个接口都不要了.呵呵.客户真TMD就是上帝.