Как сделать Modulith в Symfony

Modulith — архитектурный стиль, при котором приложение остаётся монолитом, но код внутри разбит на модули (подпапки) по доменам.

Содержание

1. Введение

2. Конфигурация модулей

3. DI

4. Routing

5. Doctrine

6. Утилиты и функции

7. Database

8. Заключение

Введение

Классическая структура проектов выглядит так:

├── src
├── Command
├── Controller
│ ├── Product
│ └── User
├── Doctrine
├── Entity
│ ├── Product.php
│ └── User.php
├── Message
├── MessageHandler
└── Kernel.php

Структура modulith в Symfony выглядела б так:
├── src
├── Product
│ ├── Command
│ ├── Controller
│ ├── Doctrine
│ ├── Entity
│ ├── Message
│ └── MessageHandler
├── User
│ ├── Controller
│ └── Entity
└── Kernel.php

Разница в том, что в modulith каждый модуль (например Product, User) содержит все компоненты в своей папке, а не по всему проекту.

Если нужна доработка условной корзины, вы сразу знаете где находится весь код отвечающий за корзину, меньше конфликтов при слиянии

Вдобавок исчезают портянки файлов, когда открываете Entity, а там 30 файлов в столбик

Часто самая большая сложность возникает у людей при конфигурации модулей. Ничто нам не мешает запихать всю конфигурацию в один общий файл, например config/services.yaml, но из-за этого файл быстро станет раздуваться, что снизит его поддерживаемость и в нем будет единая точка связности модулей.

Поэтому конфигурацию модулей лучше выносить в сами модули

Конфигурация модулей

Чтобы собрать все маленькие конфиг файлы из модулей, надо сконфигурировать ядро Symfony сделать это:

src/Kernel.php

<?php  declare(strict_types=1);  namespace App;  use Doctrine\DBAL\Types\Type; use Symfony\Bundle\FrameworkBundle\Kernel\MicroKernelTrait; use Symfony\Component\Config\Loader\LoaderInterface; use Symfony\Component\DependencyInjection\ContainerBuilder; use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator; use Symfony\Component\HttpKernel\Kernel as BaseKernel; use Symfony\Component\Routing\Loader\Configurator\RoutingConfigurator;  class Kernel extends BaseKernel {     use MicroKernelTrait {         configureContainer as baseConfigureContainer;         configureRoutes as baseConfigureRoutes;     }      protected function configureContainer(ContainerConfigurator $container, LoaderInterface $loader, ContainerBuilder $builder): void     {         $this->baseConfigureContainer(container: $container, loader: $loader, builder: $builder);         $configDir = $this->getConfigDir();          $srcDir = $this->getProjectDir() . '/src';         $container->import(resource: $srcDir . '/**/{di}.php');         $container->import(resource: $srcDir . "/**/{di}_{$this->environment}.php");     }      private function configureRoutes(RoutingConfigurator $routes): void     {         $this->baseConfigureRoutes(routes: $routes);          $srcDir = $this->getProjectDir() . '/src';          $routes->import(resource: $srcDir . '/**/{routing}.php');         $routes->import(resource: $srcDir . "/**/{routing}_{$this->environment}.php");     } }

DI

Как видно, здесь мы подключаем файлы di.php в зависимости от окружения. Эти файлы отвечают за регистрацию сервисов в Symfony и за какие-либо частные настройки модуля

Поэтому важно сказать в основном конфиг-файле не мешать нам с кастомной загрузкой:

config/services.yaml

services:     _defaults:         autowire: true         autoconfigure: true      App\:         resource: '../src/'         exclude:             - '../src/Kernel.php'             - '../src/*/{di,di_test,di_dev,routing,doctrine,functions}.php'

Пример конфигурации DI в модуле:

src/YourModule/di.php

<?php  declare(strict_types=1);  use Symfony\Component\DependencyInjection\ContainerBuilder; use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator;  use function Symfony\Component\DependencyInjection\Loader\Configurator\param;  return static function (ContainerConfigurator $container, ContainerBuilder $containerBuilder): void {     $services = $container->services();     $services         ->defaults()         ->autowire()         ->autoconfigure();      $container->import(resource: __DIR__ . '/Resources/config/notifications.yaml');      $services->alias(id: ArtifactUploadContextBuilderInterface::class, referencedId: ArtifactUploadContextBuilder::class);      $services         ->set(id: ArtifactNotificationsConfig::class)         ->factory(factory: [null, 'create'])         ->arg(key: '$parameters', value: param('artifact_notifications')); };

Файлы с суффиксом окружения будут загружены в зависимости от ENV переменной среды окружения. Например для тестов я хочу выключить кеширование, или привязать стаб вместо основной реализации:

src/YourModule/di_test.php

<?php  declare(strict_types=1);  use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator;  return static function (ContainerConfigurator $container): void {     $services = $container->services();     $services         ->defaults()         ->autowire()         ->autoconfigure();      $services->set(id: PackageProxyService::class)->arg(key: '$ttl', value: 0); };

Routing

Метод configureRoutes из Kernel.php ответственен за нахождение конфиг файлов регистрации роутов.

Тогда основной конфиг файл будет выглядеть довольно минималистично:

config/routes.yaml

redirect:   path: /   controller: Symfony\Bundle\FrameworkBundle\Controller\RedirectController   defaults:     path: /api/docs

Пример регистрации роутов:

src/YourModule/routing.php

<?php  declare(strict_types=1);  use Symfony\Component\Routing\Loader\Configurator\RoutingConfigurator;  return static function (RoutingConfigurator $routes): void {     $routes         ->import(resource: './Controller/', type: 'attribute')         ->prefix(prefix: '/api'); };

Этот файл практически всегда выглядит одинаково и просто копипастится

Doctrine

Для регистрации сущностей доктрины нужен отдельный конфиг:

src/YourModule/doctrine.php

<?php  declare(strict_types=1);  use Symfony\Config\DoctrineConfig;  return static function (DoctrineConfig $doctrine): void {     $emDefault = $doctrine->orm()->entityManager('default');      $emDefault->autoMapping(true);     $emDefault->mapping('Artifact')         ->type('attribute')         ->dir(__DIR__ . '/Entity')         ->isBundle(false)         ->prefix('App\Artifact\Entity')         ->alias('App');   };

Для этого мы должны пояснить Symfony как найти и зарегистрирoвать эти файлы:

config/packages/doctrine_module_mapping.php

<?php  declare(strict_types=1);  use Symfony\Component\Finder\Finder; use Symfony\Config\DoctrineConfig;  return static function (DoctrineConfig $doctrine): void {     $finder = new Finder();     $finder->files()->name(patterns: 'doctrine.php')->in(dirs: __DIR__ . '/../../src/**');      $load = static fn(SplFileInfo $file) => include $file;      foreach ($finder as $file) {         $configurator = $load($file);          if (is_callable(value: $configurator)) {             $configurator($doctrine);         }     } };

Утилиты и функции

Я недолюбливаю Util классы с кучей статических методов, поэтому всякие микрофункции которые особо не отнести к какому-то классу, или вам не хочется создавать и инжектить всюду класс содержащий один метод, стоит выделять просто в неймспейс своего модуля:

src/YourModule/functions.php

<?php  declare(strict_types=1);  namespace App\YourModule;  use InvalidArgumentException;  use function array_slice;  function getVendorPackageName(string $vendor, string $package): string {     return $vendor . '/' . $package; }

Только надо сказать композеру как найти эти функции:

composer.json

{   "autoload": {     "psr-4": {       "App\\": "src/"     },     "files": [       "src/YourModule/functions.php"     ]   } }

Не забудь запустить composer dump, и сбросить кеш psalm/phpstan. После добавления новых конфиг-файлов стоит запустить bin/console cache:clear чтобы симфа нашла их и обновилась.

Database

Так же как код бьется на модули (namespace’ы), так же имеет смысл бить базу данных на схемы. Это очень легко сделать:

#[ORM\Table(name: 'notification_settings', schema: 'notification')] class NotificationSettings

Тогда открывая БД, не будет пугающего списка на 800 таблиц вперемешку

Да, какие-то схемы будут содержать одну таблицу, какие-то 5, но мне лично куда проще ориентироваться в бд имея эти группы в виде схем. Плюс гипотетически это будет легче распиливаться на сервисы, если понадобится, и можно управлять доступами на схему, опять же, если понадобится.

Заключение

Понравилась статья? Подписывайся на мой тгк

Подход modulith позволяет сохранить монолитную природу приложения, не жертвуя поддерживаемостью.

Модули изолируют бизнес-логику, упрощают тестирование и дают ощущение порядка в коде. Такой подход может помочь проект к возможному переходу на микросервисы в будущем, если он вообще потребуется.