architecture - 如何使用 symfony4 实现模块化架构

Question

我想遵循 Sander Mak 的这篇文章的建议，它提倡使用传统的单体架构，使用模块而不是微服务，这在许多情况下不是一个好的选择:
https://www.oreilly.com/ideas/modules-vs-microservices

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

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

但是 Symfony 4 呢？在第 4 版之前，似乎正确的方法是使用 Bundle。但是从第 4 版开始，官方文档明确建议不要再这样做了:
https://symfony.com/doc/current/bundles.html

In Symfony versions prior to 4.0, it was recommended to organize your own application code using bundles. This is no longer recommended and bundles should only be used to share code and features between multiple applications.

但是我在文档中看不到现在正确的方法是什么!如果无法使用 Bundle，那么实现 Sander Mak 文章中定义的模块化架构的最佳实践是什么？

Answer 1

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

不要被 Symfony 4 和 5 的举动所困扰......我承认我并不总是了解他们所有的发展计划和营销策略，而且我在开始时对新的无应用程序定向发布感到沮丧。但本能地，也许是因为我没有其他选择，我努力尝试 SF4，并坚定地计划在 SF4 环境中加强我的应用程序模块化策略。

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

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

在深入探讨使用 SF4 进行模块化应用程序开发的最佳方式之前，我将分享我对 future 2 年 SF4 领导者愿景/路线图的理解:

SF4 应用程序由 2 种相互关联的应用程序模块组成:Api-component 和 Bundle

Api-Component :(谷歌说)被定义为软件系统的模块化、可部署和可替换的部分，它封装了其行为和数据，并通过一组接口(interface)公开这些。这里最重要的事实是，API 组件必须实现所需的(有界的)业务功能，并通过 API 公开。

Bundle :也是为 api-component 定义的一个组件，但粒度级别更高。这意味着，Bundle 通常使用 api-component(而不是反向)并且主要面向 User/Client 可视化界面。将捆绑视为组织的微型应用程序、功能应用程序、部门级应用程序功能的实现。例如:AccountingBundle、InventoryBundle、ProcurementBundle……粒度由每个设计团队自行决定。

从 SF4 bundleless 环境开始，Symfony 的领导者决定放弃 AppBundle，因为根据经验，他们知道创建 bundle 与组件模块的开销。因此，“App”默认组件应用程序现在是为应用程序架构师提供多种解决方案的基础环境:

'App' 组件具有 bundle 的所有功能，代码较少，但它被认为是 SF4 的核心主模块。

“App”主模块可以与所有添加的模块组件和包共享应用配置、模板、资源

平台进化考虑到提供的框架不需要知道太多关于添加的模块，默认的“应用程序”将是框架扩展的粘合剂。

在“应用程序”主模块、api 组件模块或包中实现功能现在在他们看来是代码组织决策。

恕我直言，创建组件或包的决定都是由应用程序模块化要求定义的。因此，创建捆绑包或组件模块的决定主要不是由在公共(public)空间/市场中共享代码的需要驱动的，而是由设计干净的模块化、可维护、可重用代码的必要性驱动的。

因此，在模块中拆分代码的每个决定都必须受到业务和技术要求的挑战。当您决定要创建哪些模块时，很容易在 SF4 中实现。

我对内部模块优先级的建议:

首先决定要创建哪些模块及其配置/参数要求。

使用 .env 环境实用程序的优势，将大多数配置/参数集中在“App”主模块中。

模块资源/翻译可以通过 2 个步骤创建:首先在主“应用程序”模块中进行快速简单的验证。然后，在第二步将它们移动到特定的包中...

所有其他模块使用的横向功能，例如安全性、配置和核心/通用服务，必须首先在“App”主模块中实现。有了更多的经验，一些功能可以在特色组件中重新组织，以获得更多的模块化和清晰度。

将 bundles 和 api-component 放在/src 目录下，具有中央 Composer PSR-4 自动加载能力，并将它们从“App” services.yaml 中排除

请注意，在此建议中，我们不会针对“应用程序”主模块过多地加强模块的自主性。我们选择让它们在开始时稍微依赖于中央模块配置功能。这是编码时间和验证的增益。随着开发人员在 SF4 编码规则方面获得更多经验，可以逐步加强模块封装。顺便说一下，第一个目标是及时交付应用程序。

当时间到了，并且您想与社区共享特定模块时，请检查以将外部环境所需的最小配置/参数发送回模块。