backend/
module1
module2
module3
frontend/
module1
module2
module3
modules/
module1/
frontend
backend
module2/
frontend
backend
module3/
frontend
backend
这个选择真的取决于你想要达到的目标。第一种架构是分层，第二种是关于组件。与MVC和组件（如桌面GUI等）类似的斗争。图层使您可以逐层隔离模块，这意味着您可以在现有图层上构建。这也用于IO/OSI TCP/IP堆栈。另一方面，组分更加颗粒化并且可以如此重新使用 - 例如，您可以从“小部件”组成桌面GUI。那么网络有什么更好的？对于主流，这是imho MVC，第一层架构似乎更多地使用。也许这个问题是问，如果asp.net比sp.net mvc更好...
基于你给我会去第二的信息。比我会知道该模块及其所有依赖项驻留在此文件夹中。删除此文件夹，模块消失。如果您需要更新/禁用/更换模块，则只需更新一个文件夹即可。
但是，如果这些模块不是100％单独的，而且某些情况下依赖于其他模块，我会选择第一个选项。
这实在是纯粹的个人选择。我已经构建了我的系统来隔离前端的后端代码，这样我就可以对网站数据的编辑时间和位置进行严格和精确的控制，但这只是我的方法。就我个人而言，我并不认为一种方式一定比另一种更好;无论你喜欢什么，只要你保持一致，就完全没问题。
许多框架都与您的第一种方法类似。它对于团队开发非常有效，因为前端开发人员可以更容易地与SVN等隔离到前端目录。
Symfony PHP框架松散地与第一个选项。我认为这比较好，因为只有一个部门，而不是几个部门。 – 2010-04-28 17:33:03
如果您跨2个物理层（网络服务器和业务服务器）部署应用程序，选项1可能是最合适。这种部署方式（像部署或基于安装的部署一样复制）更容易配置或运行。
为确保维护的方便性，我喜欢选项2，您可以轻松告诉开发人员开展“模块A”工作，并将他们需要的所有代码放在一个地方。
基本上，它完全是你和团队的首选。我曾与这两者合作过，这取决于您的环境，例如开发人员数量和部署策略。
适合你的那个。 – Gordon 2010-04-28 17:38:06
第一个版本看起来不那么凌乱，因此更漂亮，所以会更好;-)顺便说一句，第一个版本看起来像“范围导向”这听起来不错。 – 2010-04-28 18:02:00