Модульный PHP монолит как альтернатива микросервисной архитектуре - Юлия Николаева, iSpring

Доклад о том, как решить проблемы монолитного PHP приложения, не переходя на микросервисную архитектуру
Ссылка на презентацию: ispri.ng/2rYQK
Ссылка на статью по докладу: habr.com/ru/co...

[@leshen_deaf]

Отличный доклад! Тоже столкнулся с описанными проблемами монолита и пришел к тому же решению, что и вы. Больше всего понравилась структура доклада и целостность повествования. Ну, и спикер, конечно, тоже супер, этого не отнять)

[@nickname20151]

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

[@jmatveeva]

Рада, что было полезно!

[@ruslanm.1120]

​@@jmatveeva подскажите названия книжек не получилось расслышать? Классный доклад, в прошлом проекте делали что-то похожее, но тогда я не знал как это называется :)

[@jmatveeva]

@@ruslanm.1120 По-моему, я там упоминала книгу Vaughn Vernon "Implementing Domain Driven Design". Сейчас бы я ещё рекомендовала книгу Vlad Khononov "Learning Domain-Driven Design", must read. Есть на русском вроде бы обе, но лучше в оригинале, конечно

[@evgedoo]

Отличный доклад, много полезного почерпнул для себя.

[@MrTheKritik]

Посмотрел много докладов про ddd и ca. Этот лучший для php

[@jmatveeva]

Спасибо за обратную связь!

[@SkyengITeam]

Молодцы, что запустили движ у себя в городе!

[@iSpringTech]

Спасибо! Ждём на следующих митапах докладчиков от вас ;)

[@АнтонГубарев-в3б]

@@iSpringTech Реализовали у себя такой же монолит. Плюс минус похоже. С удовольствием поделился бы опытом)

[@iSpringTech]

Круто! Если готов выступить с докладом, напиши на [e-mail]

[@SkyengITeam]

@@iSpringTech ок, пришлем докладчика от Skyeng, как будет готов)))

[@SergeyPredvoditelev]

@@iSpringTech Случился доклад?

[@goriaev]

Вопрос с участием отвечающего парня - там паттерн аутбокс по сути обсуждали. А следующий парень хороший вопрос задал (~54 минута), только его не поняли, мне кажется, ответили "попробуйте, у нас не так". В его вопросе становится несколько единиц развертывания и он предлагает микросервисы

[@andylitunenko7938]

Первый раз смотрел, не зная основных идей Чистой архитектуры. Почитал, курсы проходил. Ещё раз посмотрел ваш доклад. Ну просто бомба, особенно идея с deptrack! Вопросы) 1. А какой у вас фреймворк? И нормально ли он подружился с вашей структурой папок?) 2. Не увидел у вас явного упоминания про UseCase. Они у вас включены в API модулей?

[@jmatveeva]

Добрый день, спасибо за отзыв! Про фреймворк не буду публично писать из-за NDA. Скажу только, что из коробки там другая структура папок, но все получилось настроить, как нам надо. UseCase - это уровень приложения, у нас они реализованы либо в виде сервисов на этом уровне, либо в виде комманд на этом уровне.

[@vladgromov9213]

Да symfony у них судя по всему. UseCases это domain services и application services

[@DimaTiunov]

​@@jmatveeva yii или свой бандл Symfony

[@goriaev]

В докладе ж вроде говорилось про то, что они не могут с ранней версии симфони слезть

[@EgorUshakov]

Восхитительный доклад! Но не понял одну вещь. Как я понимаю, для того чтобы у Order’а был Customer надо иметь что-то типа App\Module\Ordering\Order::$customerId с типом CustomerId. Но тогда получается, что модуль Ordering всё-таки знает кое-что о модуле Customer, ведь CutomerId должен располагаться примерно вот здесь App\Module\Customer\Domain\CustomerId. Или же все aggregate root id уходят в неймспейс App\Common\Domain?

[@iSpringTech]

В рамках других модулей мы работаем не с типом App\Customer\Domain\CustomerID. Обычно мы используем для хранения ID из другого модуля просто string\uuid. Если для сущности Customer нужно отображение в модуле Order, то там появляется "своя" модель, например App\Order\Domain\Customer, с ней же может приехать строгий тип для ID. В папку Common не уходят доменные типы, потому что подразумевается, что любой модуль может уехать в микросервис (а их мы пишем на go), и любые зависимости в домене от Common приведут к сложностям выноса модуля. Плюс на уровне монолита у нас прописано правило, что модуль может использовать интерфейсы\классы другого модуля только на уровне Infrastructure (вот по такому правилу в depfile - .\/src\/.*\/Infrastructure\/Adapter\/.*).

[@igor8219]

Спасибо за отличный доклад! :) Вопрос про взаимодействие модулей с помощью ACL. ApiInterface - это межпросцессное взаимодействие(rest, async) или внутри того же потока? Если межпроцессное, то как управляете транзакциями? Если внутри - то нет ли каплинга между модулями?

[@jmatveeva]

Спасибо за высокую оценку :) ApiInterface - это php интерфейс, другие модули взаимодействуют с ним, вызывая его методы в php коде (в классах антикоррупционного слоя), т.е. внутри одного потока. И да, это явный каплинг, но избавляться от него не везде есть смысл и не везде получится. А так как межмодульное взаимодействие в нашем случае имеет четкие границы (не размазано по всему коду), то контролировать его проще. Транзакции, кстати, у нас используются только внутри одного и того же модуля. Между модулями итоговая согласованность. У нас в блоге iSpring на хабре есть статья по мотивам доклада, может, пригодится, ссылка будет ниже

[@iSpringTech]

Держите ссылку :) habr.com/ru/company/ispring/blog/560074/

[@андрейандреевич-о9н]

хороший доклад для php проектов по организации модульности (фасадам) , а теперь представьте , что если между модулями взаимодействие сетевое , и не важно на чем они написаны , если вы растущая компания то вы непременно придете к микро-сервисам а точнее к сервисно-ориентированному программированию, так что я считаю что маленьким компаниям из 1,5 человека нет смысла вообще смотреть в сторону сервисно-ориентированному программированию , а уж тем более сравнивать , если вы так и не поняли в чем профит , все просто вы еще не выросли ) P.S если есть проблемы производительности то с огромной вероятностью php(not framework) не причем или это не сложно устранить в рамках php(not framework) , а вот нехватка функционала да тут уж ничего не поделаешь , но это очень узкий узкейс и в 99% случаях тоже решается

[@jmatveeva]

Спасибо за комментарий :) Все верно, на момент перехода к модульному монолиту мы ещё не так выросли, чтобы это было критично, ну и инфраструктура была не готова к микросервисам. Сейчас мы постепенно движемся в их сторону.

[@microb3726]

Информация безусловно очень интересная и познавательная. Но зачем фокусировать видео на ораторе вместо того чтобы показать что там на доске? Оператор муж ее?😊

[@moravsky5115]

*Exellent job!*

[@lytican]

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

[@iSpringTech]

Спасибо за отзыв! Юлия является архитектором в нашей компании и лично принимала участие в проектировании всего, про что говорится в докладе.

[@jmatveeva]

Да, устная речь не мой конек, признаю :) Не выступала публично со времён защиты диплома. Да и не всем мужчинам это даётся легко, не правда ли?

[@twentxx]

@@jmatveeva Вы умница 🙂

[@jmatveeva]

@@twentxx Благодарю :)

[@silentage6310]

@@jmatveeva Всё у вас хорошо, выступайте еще, было интересно.