在我多年的实践中，通过我已经完成的大部分阅读，Web应用程序项目的推荐目录结构与MVC结构密切相关：
tests/
src/
styles/
markup/
scripts/
views/
models/
controllers/
但是，我最近开始在一家新公司工作，他们的项目存储库结构奇怪（奇怪的我）。开发人员解释说他们发现这个特征结构更容易理解（我不知道这个项目结构真正被称为）。它是这样的：
app/
src/
component1/
test
view
model
controller
component2/
test
view
model
controller
当然，有些组件没有view, model, controller文件，因为它们比独立模块或业务逻辑更像是一块MVC架构。在我看来，这使得结构不那么直观。
有人可以对此有所了解吗？我觉得我对这种情况的看法是有偏见的，因为我一直都在MVC-ish / flux-like app结构中工作。
这种结构是否有优势，还是仅仅是某些开发人员缺乏经验和缺乏经验的结果？
请记住 有问题的项目是网络应用和网络服务的混合。
修改： 这个问题会与https://softwareengineering.stackexchange.com/更相关吗？
答案 0 :(得分：3)
新公司项目的结构显示出模块化设计的迹象，但很难说，因为您的示例并未包含组件/模块的真实名称。如果模块名称没有提出一些直观易懂的架构，那么问题可能是新公司的项目是Conway's law的受害者，其中指出
康威的法律是每个团队倾向于勾勒出自己领土的结果，它可以享受更多的自由，而不需要与其他人协调每一个变化。通常这会导致一些较低级别的功能在＆＃34;模块中重复出现。属于不同的团队。设计系统的组织......被限制为产生设计，这些设计是这些组织的通信结构的副本
模块化结构的另一个问题可能是，可以从不同的角度将大型系统划分为组件，并且应用错误的系统会引入不必要的复杂性。例如，您如何分解 Animal ？
如果做错了，模块化设计可能会带来更多弊大于利，因为它定义了一个框架，这将限制您对系统的思考。但是，如果没有某种形式的体系结构，大型系统就不可能存在。
答案 1 :(得分：0)
通过本文档，您将找到该解决方案