Architecture 如何使用symfony4实现模块化体系结构

我想遵循Sander Mak的这篇文章的建议，它提倡使用传统的单片架构，使用模块而不是在许多情况下都不是一个好选择的微服务：

我对单片服务和微服务进行了大量研究，得出了相同的结论，即单片服务在许多情况下仍然是最佳选择，同样的目标可以通过更简单的方式实现。微服务应该用于真正极端和特定的情况

当然，好的模块化体系结构的实现在每种语言和框架中都是不同的。作者正在谈论Java9，以及它如何完全重新定义了实现这种模块化体系结构的方式

但是symfony4呢？在版本4之前，正确的方法似乎是使用bundle。但从第4版开始，官方文件明确建议不要再这样做：

在4.0之前的Symfony版本中，建议组织您的 使用bundle拥有自己的应用程序代码。不再建议这样做，并且 捆绑包只能用于在用户之间共享代码和功能 多个应用程序

---

但是我在文档中看不到现在做这件事的正确方法！如果无法使用捆绑包，那么实现Sander Mak文章中定义的模块化体系结构的最佳实践是什么？

我来自Java环境，但我选择在SF4/PHP-7.x环境中编写当前的应用程序。在这里列举了很多很长时间的原因，让我选择了在Laravel5.x之后的SF4

不要被Symfony的4和5步犯规。。。我承认我并不总是了解他们所有的发展计划和营销策略，而且我在一开始对新的无捆绑应用程序定向发布感到沮丧。但出于本能，也许是因为我没有其他选择，我努力尝试SF4，并制定了令人信服的计划，以加强我在SF4环境中的应用程序模块化战略

感谢Sander Mak关于模块与微服务的文章，它确认了我对模块化支持框架的需求，而不仅仅是微服务模块化功能。这里真正的利害关系是正确评估您希望作为模块实现的组织概念的类型和规模。模块化的微服务肯定可以用于实现复杂的硬件、业务活动和详细的组织基础设施。但代价高昂，而且需要大量资源来处理依赖关系和相互连接

对于SF4，尽管他们通常谈论微内核或构建自己的微服务框架，但我认为他们提供的是一个很好的单片平台，用于构建模块化业务应用程序。我承认与java环境相比，PHP OOP的局限性使一些实现比预期的更困难，但最后，对于常规业务应用程序需求，SF4框架和组件提供了良好的应用程序基础

在探讨将SF4用于模块化应用程序开发的最佳方式之前，我将分享我对未来两年SF4领导者愿景/路线图的理解：

• SF4应用程序由两种相互连接的应用程序模块组成：Api组件和捆绑包
• Api组件：（google say）被定义为软件系统的一个模块化、可部署和可替换的部分，它封装其行为和数据，并通过一组接口公开这些行为和数据。这里最重要的事实是，API组件必须实现所需的（边界良好的）业务特性，并通过API公开
• Bundle：也是为api组件定义的组件，但粒度更高。也就是说，捆绑包通常使用api组件（而不是反向组件），并且主要面向用户/客户端可视界面。将bundle视为组织的小型应用程序、功能应用程序、部门级应用程序功能的实现。e、 g:会计捆绑、库存捆绑、采购捆绑。。。粒度由每个设计团队决定
• 从SF4无捆绑环境开始，Symfony领导者决定放弃AppBundle，因为根据经验，他们知道创建捆绑相对于组件模块的开销。因此，“应用程序”默认组件应用程序现在是向应用程序架构师提供多种一体解决方案的基础环境：

• “应用程序”组件具有捆绑包的所有功能，编码更少，但它被视为SF4主模块的中心
• “应用程序”主模块可以与所有添加的模块组件和捆绑包共享应用程序配置、模板和资源
• 平台演化认为，所提供的框架不需要对添加的模块有太多的了解，默认的“应用程序”将在哪里为框架扩展粘贴。
• 在“应用程序”主模块、api组件模块或捆绑包中实现功能现在在他们看来是一个代码组织决策
• IMHO，创建组件或捆绑包的决策都是由应用程序模块化需求定义的。因此，创建捆绑包或组件模块的决策主要不是出于在公共空间/市场上共享代码的需要，而是出于设计干净的模块化、可维护、可重用代码的需要
• 因此，将代码拆分为模块的每个决策都必须受到业务和技术需求的挑战。当您决定创建哪些模块时，很容易在SF4中实现
• 我对内部模块优先级的建议：

• 首先确定要创建哪些模块及其配置/参数要求
• 利用.env环境实用程序的优点，将大多数配置/参数集中在“应用程序”主模块中
• 模块资源/翻译