在查看代码时，我经常会看到MVC模式：模型，视图，控制器，表单等文件夹。表面上看起来不错，对吗？您将控制器放在控制器文件夹中，模型文件夹中的模型等等。这对于像博客这样的小型示例应用程序来说相当不错，因为您可能有5个控制器，6个模型等等。
但是，当您在更大的应用程序上工作，或者您遵循一个控制器的概念 ，一个action时，这些文件夹中的这些文件数量会迅速升级，并成为命名问题的混乱。
推荐谈话： 罗伯特“鲍勃叔叔”马丁 - 建筑：失落的岁月
我们来看一个社交媒体项目的例子。你有Walls，WallPosts，评论，PrivateConversations， PrivateConversationMessages以及更多东西。使用“经典”排列，我们将拥有相当大的目录树，即使没有前面提到的方法：
SRC |
...
这只是一个简单的例子，在现实世界中的应用程序，你就会有很多更多的控制器，模型和视图。如果根据应用程序的构造（模型，视图，控制器）进行构建，则在某个奇点之后，目录结构将变得完全无法使用。
当然，您可以使用IDE的搜索功能，但是重载的目录结构会导致您感觉有太多的类。这种感觉反过来导致害怕添加新类，您的开发人员会尝试将新功能填充到现有类中，即使它不严格属于那个类，从而导致很多单一责任原则违规。此外，这种结构使得团队中的新开发人员难以了解什么是什么。
基于意图的结构
如果我们仔细观察我们的控制器，我们可以在属于一起的东西和不属于哪些东西之间绘制线条。例如，从商业角度来看，Wall似乎是一个非常明确的概念：人们可以拥有一面墙，在上面写帖子和对所述帖子发表评论。因此，让我们将与墙相关的所有内容放入一个文件夹中。类似：
[b]src[/b] |
仍然不是很好，但更好。现在可以扩展目录结构而不必担心太多的类，如果我们正在寻找一些东西，我们可以在哪里找到它。
在我们继续之前，让我们澄清一件事：这些“模块”不是独立的。有时，如果您希望单独发布模块，它们可能具有可能需要解决的交叉依赖性，但这是另一篇文章的主题。
您可能会注意到，现在模块中的所有内容都被拿出到另外一个目录中。这很好，因为它（希望）会阻止你在一个模块中添加太多东西。但是，如果你像我一样，你仍然喜欢有一些结构构建块，所以让我们带回以前的目录结构，但是低一级：
SRC |
易于浏览和易于阅读的代码块。当然，您可以在您感觉舒适的同时，以层次结构的方式继续添加业务结构。我建议你将它保持在3-5级以下，以便轻松导航。
提示： MVC不适合作为您的总体设计模式。相反，我建议看一下 Entity-Boundary-Interactor
总而言之，您最外层的文件夹结构应该基于业务概念（意图），而不是您选择使用的设计模式。