Domain Driven Design и модульный монолит в Python

[Hramoff]

Думаю это одна из лучших статей на эту тему! Спасибо!

[vagon333]

Я бы минусанул, но религия запрещает.

@SergeyevSergey , пожалейте читателей, не переливайте с пустого в порожнее.

[Andreas_Fogel]

Возможно меня тут возненавидят, но по факту было много рассказано и показано того, что можно упростить. Получается так, что мы получаем ООП на уровне директорий, а так как мы чисто закидали ядрышко плагинами, то теперь это что то новое и модное. В итоге мы все равно делаем горизонтальное реплицирование для нагрузок, что как бы от обычного монолита ничем не отличается. То есть вообще ноль статистики о применении подхода, все думают:- я прав, я умный, я много прочитал. Вот там в тексте дяди же точно умнее меня. Ну и если вам нужен масштаб для Python проекта, то просто смените язык на Mojo, и вы сразу получите то самое увеличение производительности без покупки дорогостоящих серверов.

[bokshi]

В целом, да, несмотря на некоторые интересные наблюдения, когда видишь class IShopPublicGateway(ABC), class ShopPublicGateway(IShopPublicGateway), начинаешь грустить - так даже в джаве современной (кроме какого-нибудь солевого кружочка фанатов Мартина) никто не пишет (за ненадобностью).

При этом про самое важное (dependency injection) ничего не написано, а вроде именно он во много определяет, насколько с кодом удобно работать.

[SergeyevSergey]

То как реализовать dependency-injection сильно зависит от используемого веб фреймворка и от требований самого проекта. Поэтому подробно здесь не расписывал, как именно это нужно делать, но дал наводки на то, как можно, в зависимости от архитектуры.

[SergeyevSergey]

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

[AlexViolin]

Достаточно редкий пример статьи с полным описанием работы модульного монолита. У меня возник следующий вопрос.

Модульный монолит это отдельное приложение в рамках компьютера. Для варианта “In‑memory событийная шина” понятно как работают все EventHandler.

Для варианта “Внешний брокер сообщений” вижу такой сценарий. Каждый EventHandler должен запускать отдельный thread для просмотра списка сообщений в MessageBroker. При появлении нового сообщения, которое относится к конкретному EventHandler, этот хендлер запускает его обработчик. Уточните ваш вариант работы для “Внешний брокер сообщений”.

[SergeyevSergey]

В своей реализации я запускаю FastStream в качестве потребителя событий из брокера отдельным процессом. При этом кодовая база остается одной и той же. Меняется только точка входа в приложение. То есть у вас получается монолит только процесса обработки два - один для веб запросов, другой для потребителя ивентов. Можете назвать это "монорепо" если монолит режет слух из за нескольких запущенных процессов, главная суть в том что кодовая база остается единой. Если вы пишете синхронное Python приложение то FastStream поддерживает синхронную обработку сообщений. Если мне не изменяет память то процесс обработки там происходит почти так как вы описали, только потоки создаются на вызов а не хендлер, и складываются в общий пул после обработки, откуда потом берутся и переиспользуются для следующих запросов.

При этом если использовать паттерн Outbox вы должны запустить цикл поллера который будет дергать сохраненные события из бд и пересылать в брокер. Можно запускать его отдельным процессом, а можно и потоком внутри одного из процессов приложения, тут уж сами решайте.

[paab]

Модульный монолит — неведомый зверь, писали бы просто про него, тем более что «тактическая реализация этих идей на языке Python» получилась слабая, с постоянными оговорками.

Значительная часть статьи — это обзор способов объявить и использовать классы в Python.

Берём сложные принципы DDD, подменяем понятия, сужаем определения в угоду проекта, простоты или любой выгодной причины. Вкрапляем зависимости вроде Pydantic, противоречащие принципам, размывающие границы и ответственность. Пишем статью про своё DDD.

Зачем делать заголовки, которые не раскрываются в дальнейшем материале? Был набор принципов, взятых за основу, — и мы героически обошли их, потому что «так вышло».