Чистая Архитектура (Onion + Modular Monolith + Hexagonal) | Symfony PHP
HTML-код
- Опубликовано: 17 окт 2024
- Другие уроки Symfony смотри по ссылке boosty.to/sash...
Рассмотрим популярные паттерны для реализации чистой архитектуры приложения Symfony 6.
Onion architecture - она же "Луковая", "Многослойная" архитектура с учетом особенностей гексагонального подхода (Hexagonal architecture).
Подход Monolith First с реализацией модульного монолита (Modular Monolith).
Telegram: t.me/alejandro...
Уроки, менторство - boosty.to/sash...
Другие уроки по Symfony 6 доступны по ссылке boosty.to/sashokgorshok
Очень круто! Сразу видно что автор понимает все на архитектурном уровне! Чел ты крут!
Спасибо, вот в голове всегда была идея пилить части приложения на модули, увидел, как это реально работает.
Круто, хотілося б щє відео про архітектуру!!
Супер полезно, респект автору!
Вопрос. Здесь была показана связанность интерфейса и адаптера. А если у нас идет распил на разные контейнеры и даже на разные серваки, то каким образом мы имеем интерфейс? Он же уходит вместе с moduleX куда-то в другое место.
Когда вы выносите контекст (модуль) из монолита, нужно проделать дополнительную работу, скорее всего изменить архитектуру. Скорее всего придется выбрать другой вид связанности контекстов и другой вид контракта. В последующем уроке, под названием DDD, немного затрагивается тема связанности контекстов.
Пример.
В проекте из видео контрактом между контекстами A и B является PHP интерфейс, и его реализация. Когда модуль B выносится из основного репозитория, то вместе с ним можно перенести контракт (интерфейс из модуля A). В основном репозитории оставить реализацию API.
Вы в данном проекте используете Чтение и Запись в репозитории это правильно при данной архитектуре или упрощение? У вас в User::add() вы делаете сразу персист и флаш, как вы будите делать транзакции?
(Я вас не очень достал вопросами? :) у вас очень годный контент я бы даже сказал, что сложно найти кто еще замарочился бы на архитектуре)
Если используются 2 разных хранилища, то должны быть 2 разных репозитория. Если используются разные модели на чтение и запись, как в случае CQRS, то также могут быть различные реализации репозиториев.
У нас же единое реляционное хранилище, которое может как писать, так и читать, удалять, обновлять, и пр.
Транзакционность должна обеспечиваться на уровне агрегатов. Это будет рассмотрено на канале чуть позже в рамках урока посвященного DDD.
Благодарю за комментарии. Канал был создан с целью просвящения и обсуждения. Информация в уроке изложена в кратком формате, могут быть вопросы, и я всегда рад ответить на них.
Всем привет! Подскажите пожалуйста а что такое Shared в этой архитектуре?
Привет. Это общая директория для файлов, которые могут использоваться в разных модулях.
это прям ДДД на симфони, круто
Как всегда на высоте
Спасибо большое за твой труд , все супер , только вот один момент исправить б (PSR-2: Coding Style Guide)
Все как завещал "дядя Боб" в своей книге (стрелочек только не хватает, направленных внутрь из каждого слоя в другой, для наглядности).
Спасибо за видео. Я вообще пришел на видео это из видео по CQRS и там в комментарии написал, что смотрел пока только то видео, так как оно меня интересовало и что пользователя наверно не поймут, если им не объяснить что такое DDD. Решил вот посмотреть другие видео и увидел, что раньше объяснили. В целом концепция знакомая, единственное я кстати хоть и пишу уже лет 10 на php и много читал разного, не сталкивался раньше с концепцией first monolith и не думал что так делят изначально приложения на модули с адаптерами, чтобы потом можно было разбивать на сервисы. Почему? Уже года 3-4 как я перешел с проектов с монолитной архитектурой на микросервисную и за эти годы пока не писал ни одного проекта прям с нуля, в плане чтобы большой монолит и потом делить его на сервисы, в основном все проще - просто отдельные микросервисы сразу) Еще хотел заметить про то, что выделение в доменный слой не особо на самом деле помогает оградиться от фреймворка. Все равно те же entity (если мы говорим об их генерации через симфони и использование аннотаций от модуля доктрины) уже создают зависимость от компонентов симфони. Да их можно использовать отдельно от фреймворка, но симфони сам по себе состоит из модулей, все можно считать независимым от него)
а что думаете по поводу symfony bundles ? Кажется они решают ту же задачу. Поправьте меня пожалуйста, если я не прав.
Из официальной документации:
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.
Это не совсем то, что нам нужно, так как пееиспользовать модули в других проектах мы не собираемся.
@@AlejandroYakovlev Спасибо, еще вопрос возник по поводу адаптеров, не совсем уловил как вы предлагаете их писать ? грубо говоря, делать api запросы на беке ? иии... какие еще могут быть варианты общения ?
@@AlejandroYakovlev правильно ли я понял, что вы предлагаете использовать http client interface ?
Так Application это внешний слой
и только следом за ним инфраструктура. application это роутинг например
а инфраструктура это работа с бд
у вас неправильный порядок
правильно так
- 5 application
- 4 infrastructure
- 3 domain services interfaces
- 2 repository interfaces
- 1 domain model
поправьте если я не прав
Здесь нет понятия "правильно". Мы можете давать любые названия слоями и помещать в них разные зависимости. Если это решает конкретную проблему или делает разработку более удобной, то значит Вы идете в верном направлении. Одно скажу точно - доменный слой должен лежать в самом сердце такой архитектуры.
а вот entity это же часть doctrine со своими прокси. Не будет ли ошибкой держать его в домене, тогда как doctrine это инфраструктурный слой?
Есси бы использлвали ORM аннотации в классе сущности, это бы нарушало архитектурный принцип, так как домен зависил бы от инфраструкткрный деталей (БД, doctrine). Мы же вынесли конфигурацию маппинга на инфраструктурный слой.
@@AlejandroYakovlev Понял, спасибо. А можно еще урок по доменным событиям и event source-ингу, если получится
@@AlejandroYakovlev а в какой момент ты его вынес?
Не увидел - Hexagonal architecture или я что-то пропустил?
В чем смысл private readlonly ?
А почему сразу не делать микросервисы? Сделал сразу и забыл, а потом пилить монолит мне кажется не корректно - делаем чтобы переделать ?
Onion, Hexagonal, Ports & Adapters - все это по своей сути об одном и том же.
readlonly обеспечивает иммутабельность. private - инкапсуляцию.
Микросервисы повышают техническую сложность. Хороша ложка к обеду. Подробнее гуглите подход MonolithFirst.
"А почему сразу не делать микросервисы?" - это дороже для бизнеса и занимает намного больше времени, когда монолит можно написать очень быстро и сразу тестировать на клиенте и зарабатывать деньги, программирование - это про бизнес и клиента который хочет получить товар который приносит деньги, а когда проект доказал успешность можно и начинать переписывать на микросервисы.
@@kirilldovhaniuk4861 совсем не согласен, чувстую запах "Акварели" - в там как в мультике тяп, ляп и в продашен.
P.s. Есть така/я русская пословица - сделал дело, гуляй смело. А у тебя при 3+ проектах вся команда будет висеть на суппорте Акварели с омнокодом. Мне, используя подход monolithFirst переделать в микрушку не составляет труда и особого времени 1-3 часа и вуяля... Кирюша тебе Ленин завещал -> учиться, учиться, еще раз учиться
@@maximsymfony Есть такая украинская пословица "Не лізь поперед батька в пекло", если тебя не просят микросервисы что ты его суешь? Услышал слово микросервис и думаешь вот нужно бы его везде засунуть, а то что поддерживать их сложнее тебя наверное и не волнует.
Я не спрашивал согласен или нет, есть разные клиенты и разные запросы на разработку и поддержку, этот разговор не имеет смысла.
P.s. „Умный любит учиться, а дурак - учить.“ - Антон Павлович Чехов
@@kirilldovhaniuk4861 сладость моя, какой ты еще батька )))))) П.с. Интересно что ты осознаешь суть своей проблемы и зачем то сам себя обзываешь..... Зачем ты меня учишь, если сам дилетант? ))) Вопрос риторический
👍
Какую литературы вы читали/рекомендуете по архитектуре (и конкретно по этой)?
В описании к видео есть ссылка на репозиторий. В README описании есть чеклист, посвященный уроку, где имеютмя 2 ссылки на полезные статьи, описывающие подходы из урока.
Also
Domain Driven Design - Эрик Эванс.
Шаблоны корпоративных приложений - Мартин Фаулер.
Чистая архитектура - Роберт Мартин.
@@AlejandroYakovlev В реальных проектах вы часто используете этот подход?
@@fitter2boss72 эти практики были созданы для реальных проектов.
Существует множество различных архитектурных подходов которые решают свои проблемы. Многослойная архитектура идеально подходит для проектов со сложной бизнес логикой в большом количестве.
Будет ли урок про микросервисы?
Будет. Пока в процессе сбора материала.
Перетащил все по новым папкам и изменил адреса в конфигах, он все равно лезет в директорию контроллера по умолчанию
Чувак, ты все напутал. Ты говоришь про многослойную архитектуру, но теорию толкаешь из фреймворк-агностика. Многослойная архитектура это чуть чуть другое.
Какой у тебя может быть Domain в Shared? Учите пожалуйста мат. часть прежде чем вещать на публику. Лучше никак не учить, чем учить не правильно. Потом переучивать людей тяжало. Они уверены что Фреймворк Агностик это DDD, и когда с ними начинаешь говорить про DDD - у них не корректные представления о нем.
Без обид чел, но тебе надо трек вставить, ты расказываешь полезно и правильно, но монотоно 😢
Здоровая критика :) Как считаешь, какой трек сюда подошел бы?
@@AlejandroYakovlev любая техно мелодия, но что бы она была не громче твоего голоса :)
Вот пример, у него тоже монотон, но он вытягивает саундтреками : ruclips.net/video/OCiY60NDdaM/видео.htmlfeature=shared
Благодарю! :) Буду размышлять над этим @@ЗамирВазирханов-ы8л