多个业务的大型网站应该采用怎样的目录结构才优雅？

Question

比如豆瓣这种，那么网站应该用怎样的目录结构才优雅呢？

方法一：按对象分

这种结构能很好的划分板块，更适合人的角度

- movie
    |-- model
    |-- view
    `-- control
- book
    |-- model
    |-- view
    `-- control
- music
    |-- model
    |-- view
    `-- control
- group
    |-- model
    |-- view
    `-- control

方法二：按类分

这种方法似乎更符合计算机的角度

- model
    |-- movie
    |-- book
    |-- music
    `-- group
- view
    |-- movie
    |-- book
    |-- music
    `-- group
- control
    |-- movie
    |-- book
    |-- music
    `-- group

所以，我想知道到底应该选择哪种

Answer 1

我更倾向于第一种
理由是业务更清晰，几个模块通用的东西可能就是基础平台比如帐号什么的，完全可以做成独立的模块。将来帐号什么的要接入第三方登录，对于整个系统来说都可以不做任何变化，只改造帐号系统即可
分开的话，未来的扩展也容易实现，开发不同模块几个小组可以同时进行，代码冲突的可能性更低
将来部署的时候，针对不同的模块，可以更加容易部署到不同的服务器上

Answer 2

我喜欢第一种。
模块之间的耦合性低，如果某个模块出了问题，不会牵扯到其他模块。
当然也是方便debug。
到了一定规模就可以分模块部署。

Answer 3

我们当前的网站结构是你所描述的第二种，但是现在开发到末期了，修改一些东西深受其折磨——牵一发而动全身。不知道是不是各模块之间的耦合没有做好还是什么原因，总之我现在更倾向于第一种。像magento这种大型商城采用的是第一种，它的可扩展性就相当好，有一种插件式开发的精神在里面。

Answer 4

这样好些

Application(项目)
-- movie(项目一)
    |--- view
    `--- control
     --- config(配置)
-- book(项目二)
    |--- view
    `--- control
     --- config(配置)
-- music(项目三)
    |--- view
    `--- control
     --- config(配置)
-- group(项目四)
    |--- view
    `--- control
     --- config(配置)
-- common(模型逻辑等)
    |--- model
     --- logic
    `--- config(配置)
Framework(框架)