Ну давай рассуждать....

- не всякий под-домен достоен того что бы его вылизывать. Потому и важно выделять где core, где суппортинг а где просто купите from the shelf херню и не парьтесь
- важен единый язык и уменьшение стоимости перевода между требованиями и кодом. Термины и их значения. При этом для достаточно простых поддоменов SQL может быть неплохим способом выражать мысли
- важно общее понимание модели. бизнес не полезет код читать. Но код должен быть написан так что бы ограничения модели можно было выразить словами нормально.
- На более высоких уровнях абстракции тебя больше волновать будут границы контекстов/под доменов и как это все мэпится на код. Где какие зависимости, всякие контекст мэппинги и т.д. А то что в каком-то поддомене просто тупой круд с sql из контроллеров - почему нет. Рядом может быть колаборативный домен где у тебя будут агрегаты с сагами.

Это условно говоря... допустим мы делаем какую-нибудь звонилку и мы говорим бизнесу "с учетом того как все работает мы не сможем обеспечить больше 50-ти человек на одном звонке" (например потому что там степень от N каких-то внутренних сигналов или еще какие ограничения. И да это будет ограничение для бизнеса.

В том что ты sql в контроллерах дергаешь ограничений никаких нет

достаточно много операций где с точки зрения "моделирования" достаточно просто обозначить название юзкейса, доменный ивент какой и простенькие инварианты которые красиво можно выразить констрнейнтом в базе. Единый язык тут будет в терминах которые ты используешь для именования.

Опять же - идея о том что бы бизнесу в слух код читать немного тупая.

сложно рассуждать на новой клаве)) мысли сбиваются пока печатаешь

Как понять какой код является продуктом требований бизнеса, а какой - нет?

Мне кажется весь код такой

спросить у бизнеса "а можно это не делать?" или "а что будет если этого не будет"

Если кусок кода можно выкинуть и никто в итоге не закричит про деньги - то этот код не является продуктом требований бизнеса :)

вроде и да, а вроде и нет. В докладе про fp in ddd, докладчик рассказывал вроде как реальный кейс, когда прочитав часть кода, человек от бизнеса нашел ошибку в логике. Разве это не есть цель всего мероприятия ? единое поле проблем и решений с целью быстрых изменений модели, нахождения ошибок и т.д.

ну а еще можно DSL замутить)

http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html

в целом это скорее плюсик в копилку выразительности ФП языков нежели ДДД.

У вас аналитики всякие читают прям код?

а при чем тут это? мы про то как у нас или про методологию?

Ну имхо цель точно не в том, чтобы челы от бизнеса понимали код. А скорее чтобы разрабам легче было соотносить код и требования.

ну это инструмент который позволяет делать больше в плане целей ДДД чем без него. Люди  любят упрощать до нет VO в коде - у вас не ДДД, типа как будто это слон, и если нет хобота - то не слон (хотя и в этом случае звучит как бред). Потом рождаются высказывания типа ДДД это дорого (wut?), хотя там нет четких критериев черного и белого (есть ДДД или нет ДДД) и у каждого бизнеса в каждый момент времени отличаются cost/benefit движения к идеологически-чистой доменной модели.

но никто ж и не пушит кроме отрицателей

но одно другому никак не противоречит

вот забавно, то есть "sql размазанный по контроллерам вполне DDD" с твоих же слов) Во всяком случае критерием будет не че там в коде а есть или нет процесс моделирования предметной области

Идеологически неверно. Вае зависит от контекста обсуждения. Если методологию обсуждать - то неверно, а если как этого сферичкского коня в вакууме на реальную жизнь натягивать - то ничего криминального конечно же нет

я запутался. Идеологически неверно судить есть ддд или нет по коду или идеологически не верно обсуждать код или идеологически не верно утверждение что "можно и sql размазывать по контроллерам и при этом DDD"? Если последнее то огласите весь список критериев кода для того что бы соответстовать DDD