Comments 13
Отлично написано! Круто, что не слово в слово с доклада, интересно читать! А файл для deptrac с последней версии взят? Там вроде немного формат регулярок изменился
Интересная метафора у "паттерна", первый раз, если честно, слышу, что есть такой паттерн. Думаю, что многие в это время (мы начинали в декабре 2018 и зарелизились к дню космонавтики 2019 :) шли аналогичным путем и пришли к похожим решениям. Бегло посмотрела описание, выглядит похоже, но разница в том, что у них sections - полностью изолированные друг от друга части и могут общаться только через шину или сеть. У нас же код модулей может взаимодействовать друг с другом непосредственно. Нечто похожее делали в skyeng, тоже рассказывали на одном из митапов. У них модули взаимодействовали через rest.
Хотелось бы чуть лучше разобраться в тех преимуществах, которые даёт «чистая архитектура», потому что на первый взгляд это похоже на overengineering. Также хочется хотя бы мельком взглянуть на ApiInterface и Adapter модулей, чтобы понять, как они взаимодействуют.
Деление на слои у нас только внутри модуля. Валентин про структуру внутри модуля вроде бы не говорил (не помню). Модули общаются так же путем непосредственного взаимодействия классов, просто не всем классам это разрешено, а только тем, которые расположены в папке Adapter с вызывающей стороны и в папке Api с вызываемой стороны. Все остальное только для внутреннего использования.
Насчёт overengineering. Основное преимущество, на мой взгляд, это отделение доменной логики от всего остального. Во-первых, код домена становится чище, во-вторых, бизнес-логика считывается лучше, так как свободна от всяких технических деталей. В-третьих, покрывать ее модульными тестами становится гораздо проще. Ну и ещё, возможно, не всем подходящий плюс - можно поручить написание бизнес-логики более опытным (сильным или погруженным в предметную область) разработчикам, а все остальное - разработчикам послабее.
Но эти преимущества имеют место быть только при наличии ярко выраженной доменной логики. Если это обычный круд, то заморачиваться, имхо, не стоит.
Примеры постараюсь накатать.
Большое спасибо за статью, очень интересно и познавательно.
Вместе с тем у меня возникло пару вопросов. Первый - относительно сериализации/десериализации событий. Допустим модуль Ordering диспатчит ивент OrderPaced, который сериализуется в JSON и уходит в EventBus. На это событие подписан модуль Notification. Со стороны модуля Notification получив событие вы же не с array/stdObject работаете? Событие десериализуется в некий обьект OrderPaced, который относится уже к модулю Notification?
И второй вопрос относительно событийности. Вы написали:
мы можем внести в нашу инфраструктуру брокер сообщений и общаться между собой посредством событий
В моём понимании общение посредством событий через брокер - это асинхронщина. В таком случае как вы совладаете с ней (если это действительно асинхронный брокер, например amqp). Если моё предположение ошибочно - напишите, пожалуйста, что конкретно вы имели в виду?
Большое спасибо )
По первому вопросу все так, как вы предположили. Да, в модуле Notification все преобразуется в объект "родного" для него класса. И, кстати, набор свойств у этого события может быть другой, такой, который интересен этому модулю. Скоро должна выйти статья в нашем блоге про наш диспатчинг событий, следите за обновлениями :) Там же будут ответы и по второму вопросу, хотя я не поняла, что вы имеете ввиду под "совладать" с асинхронщиной. Да, события обрабатываются асинхронно, и мы (и бизнес в том числе) принимаем, что в этом случае данные будут иметь не транзакционную согласованность, а итоговую (eventual consistency).
Очень понравился подход, а можно получить какую-то болванку на примере реализации модуля, чтобы были разные виды API Gateways реализованы для него?
Модульный PHP монолит: рецепт приготовления