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

а вот весь этот булшит на гитхабе в стиле "мы тут репозитории дата мэпперы и прочий булшит по папкам раскидали" - это не про DDD. Глупо искать даже "примеры DDD" потому что это будет как смотреть на стоп кадр, вся сложность в том как все эти вещи формируются и меняются со временем. А папочки и репозитории всякие - есть куда более простые штуки с которыми будет то же самое получаться.

если очень хочется поиграть в DDD - лучше попробуй составить диаграммы юзкейсов, повыделять экторов, кто че делает, кто на что влияет, где инварианты стэйта и вокруг этого уже ищи границы твоих агрегатов/сущностей. Можно поиграть во всякие process modeling event storming, тоже помогает немного. Можно попробовать выделить на основе всего этого bounded context и поиграть во всякие bounded context mapping, составить всякие bounded context canvas (https://medium.com/nick-tune-tech-strategy-blog/bounded-context-canvas-v2-simplifications-and-additions-229ed35f825f)

ну то есть вот даже вопрос "размеры". "цвета" и прочие характеристики товаров - на что влияет, как это все привязано к управление стоком и т.д. Нужно понимать жизненный цикл этого всего, мол поступления в продажу, кто заполняет инфу, как оно там на складах пополняется, кто будет это дело потом со складов в доставку оформлять и т.д. Сложность она вот там обычно, в бизнес процессах которые "пользователям не видны"

Благодарю за развернутый ответ.
Проблемы понял. Буду потихоньку разгребать вышенаписанное

https://www.amazon.com/Strategic-Monoliths-Microservices-Addison-Wesley-Signature/dp/0137355467 Vernon решил хайпануть

> associated anti-pattern of components building their own dependencies during initialization

Воу. С каких пор это антипаттерн. Это может быть как хорошо, так и плохо.

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

Это не из книги, если что)

@shieldy_bot @Enleur

@fes0r 👋 Подскажи плз, не проскакивал здесь холивар на эту тему? Или может что есть подкинуть по сабжу 🤔

Chirag Patel, please, press the button below within the time amount specified, otherwise you will be kicked. Thank you! (60 sec)
Powered by Todorant

А из какой статьи это?
Можно линк плиз)

Благодарю!

Но статья неоч, как и в целом идея втаскивать DI в Go

до сих пор интересно как на средне-больших проектах без контейнера там живут)

Проекции и прожекторы это то откуда появляются рид-модели?

+1. Не понимаю, какие у DI альтернативы

Dependency elimination принцип 🌚

В целом видал инстанцирование неявных зависимостей внутри модуля. Не сказать что это так уж плохо 🤔