Книга топ, но правда не дает ответа как решения книги масштабировать, когда у тебя в сервисе больше 1 api метода) Скажем, как быть, когда есть связи между агрегатами и тд
Хай! Надеюсь кто-то мне объяснит 2 момента по этому видео. Ни в коем случае не хочу критиковать, хочу разобраться для себя. 1 - в джанге очень давно было популярно тонкие вьюхи, жирные модели. То есть пихали всю бизнес логику в модели. Но потом поняли, что это становиться неподдерживаемым - файлы на десятки тысяч строк, Год обджект (нарушает солид ) и все такое. Начали выносить логику в отдельные сервисы, а модель - анемичная. Ну может какие-то проперти. В ДДД я так понял продвигаеться опять Домен и Агрегат - тот Год обджект. А как же солид? 2 - ивенты. По сути в джанге есть реализаци ивентов - сигналы. И тоже есть десятки статтей, что это антипаттерн и лучше их не использовать, потому что логика становиться очень запутанной, и что бы понять что куда приходит, и что как вызываеться иногда без дебагера вообще невозможно. И тут опять о них говорят, как о чем-то хорошем. Так все-таки кто же прав? Почему нельзя использовать ДДД, но следуя солид? И что по сигналам? (ивентам)
тут нужно сделать несколько пояснений, а именно: 1. джанга не есть пример лучшего архитектурного решения как таковая, а является отличным инструментом для решения определенных типов задач 2. ДДД распространяется на всю парадигму, а не на конкретный фреймворк (джанга, фласк и т.п.), и где-то нет "сигналов" и пр., да и работа таких механизмов сильно зависит от много и может не совпадать с результатами ожиданий) Чтобы больше понять о чем говорит автор видео, там выше парни рекомендуют прочесть "Паттерны разработки на Python" Персиваля, либо обратиться к Эрику Эвансу, но там больше про Java, но смысл будет наверное понятен. А так, нет, в самом GodObject или "Комке грязи" наблюдается высокая связанность компонентов и высокое сцепление, что противоречит самим принципам солида, ДДД же пытается наоборот это исправить))
@@felix30ua Сорри, жаль твоего времени (и моего). Ибо я не увидел ответа на мои конкретные вопросы. То есть коментарий абсолютно бесполезен (для меня). Но может кому-то сгодиться. Плюс поможет в продвижении видео.
Непонятно зачем мы в репозитории два раза перебираем ивенты, сначала из агрегата а затем из ивентхендлера
На python тоже есть книга про ddd и event driving
Паттерны разработки на Python: TDD, DDD и событийно-ориентированная архитектура
@@MaksimG73577 полная шляпа, лучше даже не смотреть
Книга топ, но правда не дает ответа как решения книги масштабировать, когда у тебя в сервисе больше 1 api метода)
Скажем, как быть, когда есть связи между агрегатами и тд
Хай! Надеюсь кто-то мне объяснит 2 момента по этому видео. Ни в коем случае не хочу критиковать, хочу разобраться для себя.
1 - в джанге очень давно было популярно тонкие вьюхи, жирные модели. То есть пихали всю бизнес логику в модели. Но потом поняли, что это становиться неподдерживаемым - файлы на десятки тысяч строк, Год обджект (нарушает солид ) и все такое. Начали выносить логику в отдельные сервисы, а модель - анемичная. Ну может какие-то проперти. В ДДД я так понял продвигаеться опять Домен и Агрегат - тот Год обджект. А как же солид?
2 - ивенты. По сути в джанге есть реализаци ивентов - сигналы. И тоже есть десятки статтей, что это антипаттерн и лучше их не использовать, потому что логика становиться очень запутанной, и что бы понять что куда приходит, и что как вызываеться иногда без дебагера вообще невозможно. И тут опять о них говорят, как о чем-то хорошем.
Так все-таки кто же прав? Почему нельзя использовать ДДД, но следуя солид? И что по сигналам? (ивентам)
тут нужно сделать несколько пояснений, а именно:
1. джанга не есть пример лучшего архитектурного решения как таковая, а является отличным инструментом для решения определенных типов задач
2. ДДД распространяется на всю парадигму, а не на конкретный фреймворк (джанга, фласк и т.п.), и где-то нет "сигналов" и пр., да и работа таких механизмов сильно зависит от много и может не совпадать с результатами ожиданий)
Чтобы больше понять о чем говорит автор видео, там выше парни рекомендуют прочесть "Паттерны разработки на Python" Персиваля, либо обратиться к Эрику Эвансу, но там больше про Java, но смысл будет наверное понятен. А так, нет, в самом GodObject или "Комке грязи" наблюдается высокая связанность компонентов и высокое сцепление, что противоречит самим принципам солида, ДДД же пытается наоборот это исправить))
@@felix30ua Сорри, жаль твоего времени (и моего). Ибо я не увидел ответа на мои конкретные вопросы. То есть коментарий абсолютно бесполезен (для меня). Но может кому-то сгодиться. Плюс поможет в продвижении видео.
@@andrewmoon181 не берите в голову, значит оно вам не нужно, живите как жили и не парьтесь.
захотите разобраться - читайте книги)
@@felix30ua Сначала хотелось бы получить все-таки ответы
луковую архитектуру понял ) и все ( ... выключил )