*не только ddd

Ну типо правильно подметиили, что если предметная область ложится на запросы SQL, то SQL в контроллерах вполне DDD, хотя тип мы не изолировались от интерфейса хранения

Как предметная область может ложиться на запросы SQL?

Я навреное неправильно сформулировал:
хотел сказать, что SQL может быть для конкретной предметной области подходящим способом моделирования

Всё равно не очень понятно. Как будто ты имеешь ввиду ORM как Entity. Но это же протёкшая инфраструктура

И тем более, если ты имеешь ввиду чистый SQL:)

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

Ну так прямые скл запросы из контроллера/репозитори-слой/другое, это уже детали реализации
Если подразумевается что не будет изменений в этом, то можно напрямую накидать

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

Даже если и будут изменения - накидать всё равно можно

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

Понял. Я подумал за изменения по бизнесу

там вопрос специфичности/стабильности операции.

Выборки на чтения как правило настолько же стабильны как и требования к этой выборке. То есть грубо говоря некий SQL запрос который возвращает тебе списочек будет использоваться строго для этой выборки в UI.

Есть варианты подразумевающие композицию запросов (типичный кейс - всякие поиски где резалт сэт одинаковый но меняются условия выборки). Но это шо с репозиториями что просто с sql решается одинаково.

В целом это надо обсуждать всякие stable dependency principle и прочие abstract dependency principle а так же как часто и почему меняется чего. Если что - "поменяли хранилище" это очень редкое событие в жизни продукта и там последствий сильно много. Это обычно называют критерием хорошей изоляции но нужна она тебе или нет в том или ином месте ты можешь прикинуть попробовав придумать изменения требований и оценить его вероятность.

проблемы могут быть если мы в этих SQL лезем куда-то за пределы границ нашего модуля (если мы про структурированный монолит например). Это все можно решить так же как и в ситуации с микросервисов - запретить баловаться с чужими схемами и юзать агрегацию данных где-то на уровень выше (чет типа application side join).

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

Ну и дальше уже всякие колаборативные домены где уже можно играться в CQRS.

А чем sql не язык программирования которым можно выражать предметную область? Иными словами также как на джаву

Очень интересно @fes0r @dmitriytk

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

Если на пыхе — вообще огонь 🤙

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

И дзен и тлен сразу...

Затрите про FSM.
Вот есть стейт паттерн, на хабре есть статья предлагающая альтернативу, где стейт паттерн хаят.
https://habr.com/ru/post/160105/

Вопрос, почему стейт паттерн хаят?

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