Использование паттерна D-MVC в приложении Symfony

🗣 Наша история

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

История началась с:

Я собираюсь разработать систему управления конференциями. Она должна содержать различные домены: управление пользователями, твиты и рейтинг, расписание выступлений, регистрация и SSO. Разработка должна учитывать эти домены.

Посмотрите обзор дизайна системы управления конференциями

🤯 Наша задача

У большинства наших разработчиков может быть меньше опыта в проектировании программного обеспечения, особенно сложных систем. Такие архитектуры, как Onion architecture, Hexagonal Architecture или Clean Architecture могут быть излишними для большинства из них, которые имеют меньше знаний о проектировании. Но все они хорошо знают паттерн MVC, который на самом деле является родным паттерном, используемым в стандартном проекте Symfony.

😎 Бинго! Архитектура D-MVC

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

MVC является наиболее известной архитектурой, которая широко используется в ruby on rails и Symfony framework.

Но что такое D-MVC? 😱
На самом деле, он просто основан на принципе MVC, но вдохновлен распространенным паттерном duck-redux от Frontend-world. подробнее о том, что такое redux ducks?

Ducks — это модульный паттерн, объединяющий действия, типы действий и редукторы, которые используются в реализации redux.
Поскольку структура проекта выглядит как утки в ряду, смотрите изображение ниже 😀

руководство в duck-MVC: мы построили различные модули (т.е. утки), которые строго спроектированы и реализованы в паттерне MVC.

🚀 Каждый разработчик хорошо знает MVC.

Поскольку каждый разработчик хорошо знает MVC, нет необходимости обучать его. Мы можем легче и быстрее приступить к работе.
Чтобы сделать проект более привычным для стандартного проекта Symfony, я сохранил слой View по умолчанию в Symfony framework, т.е. все представления по-прежнему находятся в папке /templates.

Каждый duck должен содержать только три части:

• Контроллер: контроллер веб-запроса или запроса API
• Модель: все специфичные для домена сервисы, модели, которые обычно используются контроллером.
• View: на самом деле они находятся в папке /templates (Это стандартный путь из фреймворка Symfony. Я сохранил все как можно проще. Конечно, его можно перенести и непосредственно в папку duck :: user).

Основываясь на этом D-MVC подходе, мы можем создавать различные модули для бизнес-доменов. Его можно очень легко масштабировать, добавляя больше модулей.

• Расписание: модуль для управления расписанием переговоров
• Безопасность: модуль для управления аутентификацией и SSO
• Tweet: модуль для управления твитами и рейтингами конференции.
• Пользователь: модуль для управления пользователями
• … другие модули

✅ Выполнение задач

Самое приятное в этом подходе — это возможность увеличить скорость работы команды при меньших знаниях в архитектуре программного обеспечения. Кроме того, в этом подходе я учитываю следующие важные моменты:

Домен

Я не делю домены на части и не распределяю их по различным ducks. Потому что большинство из них являются общими для разных доменов. Объединение их вместе снизит стоимость обслуживания, и код может быть дружелюбно разделен между ducks.

Папка domain содержит наиболее важные материалы, связанные с доменом:

👥 Заключение

Это решение является хорошим подходом для команды, которая имеет меньше знаний об архитектуре. Оно позволяет максимально эффективно использовать усилия команды, не тратя много времени на обдумывание того, куда мне следует поместить файлы. Разработчик должен просто следовать основным принципам, которые он изучил в прошлых проектах MVC. Все должно работать.

Кроме того, у нас есть еще несколько ценных побед:

• масштабируемость: Проект можно очень легко масштабировать. Он все еще сохранит проект в очень четкой структуре, если домены проекта станут сложными.

• Простота: в этом решении нет никакой магии, оно очень прагматично. Каждый разработчик может очень легко начать работу с этой установкой, и для этого требуется меньше знаний в области проектирования.

• доменно-ориентированное: потому что мы стараемся создавать небольшие ducks для специальных доменов. Это помогает и бизнесу, и разработчикам как можно быстрее отследить проблему в целевой области duck.

• Мобильность: Каждый duck имеет стандартную структуру MVC. Код может быть очень легко преобразован в micro-service, если это необходимо.

Эта статья, возможно, не может быть использована в качестве шаблона решения, потому что есть еще кое-что, что не включено и не объяснено. Но она может послужить вдохновением для поиска прагматичного решения для веб-разработки Symfony. Если это поможет вам или если у вас есть вопросы, не стесняйтесь писать в комментариях или свяжитесь со мной напрямую.