конечно не умещается

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

почему не назвать это ДДД, если язык есть, все присущие атрибуты есть, и сложность законтролена

то есть некая абстрактная "сложностЬ" мешает мне называть ДДД?

Сложность предметной области относительно сталая величина.
Сложность кода управляема на определённую величину в обе стороны (с ддд - лучше, без ддд - хуже).
Если ещё проще - для меня “трушной ддд реализацией” является качество её внедрения вне кода

ваш довод ранее "конечно станет сложнее" попадает под эти доводы

второй довод не про программирвоание, а про бизнес-проектирвоание
даже не про проектирвоание со стороны СТО

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

“абстрактная "сложностЬ" мешает мне называть ДДД?” - нет, вы в праве называть что угодно как угодно. Я лишь аргументирую свою субъекивную позицию восприятия между “тру ддд” и просто “ддд”. Можно ещё рассуждать и про “вообще не ддд” но не вижу смысла

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

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

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

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

@maxisgrom ты точно не путаешь ддд с доменой моделью? или может быть ты только за тактический ддд пишешь?

Смотря что вы имеете ввиду под тактическим ддд 🙃

То есть основной критерий трушности — сложность и количество правил?

Тот факт, что есть контексты попроще, но ещё сложны для описания не языком бизнеса и будут  облегчены разбиением — не ддд?

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

При этом сложные для понимания человеком, но не банк и не нефтянке — не ддд?

Тут напрашивается вопрос не тру или не тру, а сложно или не сложно

“То есть основной критерий трушности — сложность и количество правил?” - Сложность предметной области и наличие работы с этой сложностью на всех уровнях компании/проекта (читайте - в том числе вне кода)

“Тот факт, что есть контексты попроще, но ещё сложны для описания не языком бизнеса и будут  облегчены разбиением — не ддд?” - ддд. Просто не факт что его использование будет оправдано при таком раскладе (опять таки - это моё субъективное мнение)

понимаю набор паттернов и строительных блоков фокус которых направлен на имплементацию в коде и построение доменной модели

Тогда, если проще, я пытаюсь отойти от обсуждения кода

Но код ненефтянной логики может быть все ещё сложным для программистов

Да, безусловно

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