местами да, есть сложные узлы
а только сложную описывают?

код воплощает логику, на языке бизнеса... что еще надо для внедрения ДДД практик?

мы сейчас не о UI говорим, а именно о логике

для UI все просто, да

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

что за оверхед такой, чем сложен ДДД?

есть язык бизнес-прцоессов, они описаны кодом... почему мне НЕ описывать бизнес-прцоессы кодом?

круду есть место, тоже, да
в простых местах

есть очень изолирвоанные места, там говняшкам есть место, дабы не усложнять

Да ничем не сложен. Разве что внедрить его на уровне компании не всегда просто, но это другое.
Я ж не отговариваю вас от ддд. Понятное дело что и блог на ддд можно писать, и туду-лист тоже 🙃

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

ну а что за тру-реализация:
- есть процессы
- процессы описаны
- в рамках процессов есть стейт, который контролируют сущности внутри себя

по итогу и сущности небольшие, и код не сложный

может показаться, что просто, но если десяток юзкейсов вынести (куда?) и все представить анемичными сущностями,  то какой бордак выйдет... проверок и бизнес-правил то много

десяток юзкейсов — это много для анемичной сущности

там же выносить не только логику, а еще контроль стейта наружу... это я считаю сложным

ДДД соблюсти вполне можно малым и простым кодом

Тру реализация в моём представлении это когда ддд применяют в достаточно сложных процессах/доменах, где его применение действительно может быть оправданно. Где ддд внедрён на уровне менеджмента проекта/компании, где присутствуют внешние или внутренние эксперты которые через призму языка предметной области пытаются находить общий язык со специалистами переводящими знания в код.
Соответственно, не тру а просто реализация ддд - это всё остальное что не подошло к описанию выше

“ДДД соблюсти вполне можно малым и простым кодом”  - в общем и целом - да. Только ддд по натуре своей это не только про код. Именно потому в моём мире трушная реализация его это в том числе реализация вне кодовой базы

ну все верно, знания в виде кода, я об этом же...
моя логика станет сложной, если от моего "не тру. ДДД" избавиться и вернуть к круду/процедурному подходу

у меня есть около десятка контекстов, в каждом из них по десятку/полторадесятка юзкейсов, этого достаточно держать в описании проиходящего в виде простого кода

эксперты и внутренние и внешние — это я, я же программист
мне сложно было бы вернуться к паутине нерелевантного к процессу коду

“моя логика станет сложной” - безусловно станет. Только на сложность предметной области это не влияет

ну тут и принципиальное расхождение

есть логика (как бы то нибыло), и мне говорят "не тру ДДД", делай сложнее
а я говорю "ДДД" и "сложно конечно не станет"

то есть у тебя расхождение, логика кода стала проще, но не тру все равно?

ну ок... но ДДД же, описал и погасил сложность, добавил ясности
чем не ДДД, не понятно

Ну вот я об этом же. Если у вас в голове умещается вся сложность предметной области и за бокалом пива вы сможете её объяснить коллеге-программисту за пару вечеров - для меня эта сложность не будет являтся эталонной сложностью для оправдания ддд. Это совершенно не значит что вам не нужно применять ддд в коде, я лишь апеллирую к субъективной трушности со своей колокольни