我们什么时候应该在php Phalcon中使用多模块结构（而不是简单结构）？
我发现了一些多模块骨架，例如：
https://github.com/ovr/phalcon-module-skeleton，
https://github.com/phalcon/mvc/tree/master/multiple。
但是我不知道我应该在项目中使用这种多模块结构而不是使用多个项目。我可以考虑的是：更复杂的配置，复杂的文件夹结构，我的 web url 更长（/[模块]/[控制器]/[操作]），重要的是，性能会很低（对于更多的加载内容）。
但是，我认为它有一些有趣的东西（很多ITer都使用它）。有没有人可以给我优点、缺点和选择标准。
P/s：Zend2 模块也有同样的问题！
如果要将单一用途应用程序构建为不使用视图的 API，则应使用单模块结构。如果它是一个非常简单的API，例如存储/日志记录，微应用程序也可以。
如果您愿意构建更复杂的解决方案，多模块应用程序结构非常有用。例如，具有公共内容但具有管理面板的公共应用程序。这将很方便地编写多模块以将管理控制器/视图与那些公共控制器/视图分开。
我的习惯是使用多模块结构，因为大多数情况下，我必须构建带有API和公共可访问内容部分（例如文档）的CRM应用程序。为此，创建以下模块非常方便：
- 前端 - 适用于每个人都可以访问的控制器
- 后端 - 用于在身份验证和授权后访问的控制器，例如管理事项 API
- - 用于 API 目的 ;)
- common - 我宁愿不实现的一部分，但是在一个项目中，我被迫在这里放置一些抽象的控制器，这些控制器将在其他模块中扩展。
通过这种方式，您可以为每个模块保留单独的服务配置，从而避免切断模块 A 中使用的内容，但不在模块 B 上使用的东西。像身份验证部分 - 对后端很重要，但对前端部分无用。或数据库配置 - 前端从站，后端主站等。因此，对于大型项目，这也可能是性能明智的解决方案。
更新
有时"多项目"是一种选择，包括"多模块"项目;)这在很大程度上取决于您要实现的目标。例如。如果将 API 拆开，则在多个实例上扩展它可能更容易，但首先配置单独的项目需要花费 efford。
如果系统应该是单服务器实例，或者每个实例都应该绝对独立于其他实例，那么单个多模块项目就足够了 - 比如说一个标准的CMS，博客平台，甚至是简单的浏览器游戏或移动应用程序的主页，包括它的API。但是，如果您正在构建一个完整的应用程序，例如用于特权内容的内部 API、用于管理内容的 CRM 以及用于为其服务的几个网页，那么将它们保留为单独的项目将在以后更容易管理。
例如，我在我的应用程序中拆分了每个功能-例如，我有模型链接-将其拆分为单独的模块，以具有良好的应用程序结构，其中每个功能都是单独的模块。这就像在加载器中加载的类更少。因为你只需要每个模块的模型和路由来加载整个应用程序，并且你在模块中加载其他东西，如库/控制器/帮助程序/服务。