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

Question

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

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

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

但是Symfony 4怎么样？在版本4之前，似乎正确的方法是使用Bundles。但是从版本4开始，官方文档显然建议不再这样做了： https://symfony.com/doc/current/bundles.html

  

在4.0之前的Symfony版本中，建议组织您的   使用bundle自己的应用程序代码。这不再推荐了   bundle只应该用于共享代码和功能   多个应用程序。

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

Answer 1

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

不要被Symfony 4和5移动犯罪......我承认我并不总是理解他们所有的进化计划和营销策略，而且我在开始时对新捆绑包感到沮丧申请方向宣布。但本能地，也许是因为我没有其他选择，我努力尝试使用SF4环境中强有力的应用程序模块化战略来确定SF4。

感谢Sander Mak关于模块与微服务的文章，因为它确认了我对模块化支持框架的需求，而不仅仅是微服务模块化功能。这里真正的重点是正确评估您希望作为模块实现的组织概念的类型和规模。模块化的微服务肯定可用于实现复杂的硬件，业务活动和详细的组织基础架构。但是代价高昂，并且有很多资源来处理依赖关系和内部联系。

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

在深入探讨将SF4用于模块化应用开发之前，我将在接下来的两年中分享我对SF4领导者愿景/路线图的理解：

• SF4应用程序由两种类型的互连应用程序模块组成：Api-component和Bundle
• Api-Component：（google say）被定义为软件系统的模块化，可部署和可替换的部分，它封装了它的行为和数据，并通过一组接口公开这些部分。这里最重要的事实是，API组件必须实现通过API公开的必需（有界限的）业务功能。
• Bundle：也是为api-component定义的组件，但具有更高的粒度级别。这意味着，Bundle通常使用api-component（而不是反向），主要面向User / Client可视化界面。将bundle视为组织的迷你应用程序，功能应用程序，部门级应用程序功能的实现。例如：AccountingBundle，InventoryBundle，ProcurementBundle ......根据每个设计团队的口味保留粒度。

• 从SF4 bundle less环境开始，Symfony领导者决定放弃AppBundle，因为根据经验，他们知道创建捆绑包与组件模块的开销。所以，应用程序＆＃39;默认组件应用程序现在是向应用程序架构师提供许多解决方案的基础环境：

• 1. ＆＃39;应用＆＃39;组件具有捆绑的所有功能，编码较少，但它被视为中央SF4主模块。
  2. ＆＃39;应用＆＃39;主模块可以与所有添加的模块组件和捆绑包共享App配置，模板，资源
  3. 平台演变认为所提供的框架不需要了解更多关于添加模块的信息，以及默认的应用程序＆＃39;将是框架扩展的粘合剂。
  4. 在“应用程序”中实现功能。主模块，或api组件模块或捆绑包现在是他们观点的代码组织决策。
  5. 恕我直言，创建组件或捆绑包的决定全部由应用程序模块化要求定义。因此，创建捆绑或组件模块的决定主要不是由在公共空间/市场中共享代码的需要驱动，而是由设计干净的模块化，可维护，可重用代码的必要性驱动。
  6. 因此，每个在模块中拆分代码的决定都必须受到业务和技术要求的挑战。当您决定创建哪些模块时，它很容易在SF4中实现。

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

  1. 首先确定要创建的模块及其配置/参数要求。
  2. 将大多数配置/参数集中在“应用程序”中。主模块，使用.env环境实用程序的好处。
  3. 可以分两步创建模块资源/翻译：首先在主要＆＃39;应用程序＆＃39;模块，用于快速简便的验证。然后，在第二步中将它们移动到特定的包中......
  4. 所有其他模块使用的诸如安全性，配置和核心/公共服务之类的横向功能必须首先在应用程序＆＃39;主要模块。凭借更多的经验，可以在特色组件中重新组织某些功能，以实现更高的模块化和清晰度。
  5. 将bundle和api-component放在/ src目录下，具有中央作曲家PSR-4自动加载功能，并将其从“应用程序”中排除。 services.yaml
  6. 请注意，在此建议中，我们并没有过多强调模块对“应用程序”的自主权。主要模块。我们选择让他们在开始时稍微依赖于中央模块配置功能。这是编码时间和验证的增益。随着开发人员在SF4编码规则中获得更多经验，模块封装可以逐步加强。顺便说一句，第一个目标是及时交付应用程序。

当时机成熟，并且您想要与社区共享特定模块时，请检查发送回模块，外部环境中所需的最小配置/参数。