Ну до собеса обещали от 5к

гривен?

Евро-гривен

это которые на майдане были?

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

Жиза

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

У ддд есть четкое определение, как и методик его авторов

Так что тут в споре мне куда легче

Вы сами выше давали критичный для вас критерий трушности  в виде «сложности»
Потому вы же и провели деление

Не вижу связи между наличием критерия в виде сложности и делением разработки софта на бизнес и не бизнес.

Не понял вас, что за деление?

Ну это же ваша фраза - “Потому вы же и провели деление”

Моя фраза относительно сложности

Вы прицепили сложность к признаку ддд

Я предлагаю сложность бизнеса оставить характеристикой  бизнеса, а не как признак наличия ддд

Иными словами, я предлагаю ддд применять на разном уровне сложности, достаточном упростить и синхронизировать код с бизнес-процессами, а не только не каком-то «сложном»

По примеру выше: я описал о наличие 15 процессах в рамках одной сущности… все выражены языком и подходами, описанными авторами методологии, что и назвал ддд

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

От противного: в проекте значит ддд

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

А почему вы отделяете-то? Ведь DDD призван в том числе для управления и контроля сложности, через призму единого языка. Чем выше сложность тем оправданее использование подходов вида DDD. Как и говорил ранее - если у вас нет “большой сложности” то у вас нет с ней проблем! 🤷‍♂️ Вы можете использовать архитектурные подохды, паттерны, принципы пакетной разработки, SOLID, etc. и писать понятный, прозрачный, поддерживаемый код, без потребности выделять агрегаты, проводить границы контекстов и формировать единый язык предметной области и проводить прочие церемонии из DDD.
Будет ли хуже если писать что-то без DDD - возможно будет, или скорее всего будет. Можно ли написать условное что-то хорошо но без DDD - можно, если не использовать ничего другого что позволяет контролировать качество описания предметной области. Понимаете, это как Scrum. Он в многих командах но почти нигде вы не встретите чистый Scrum. Команды пытаются внедрять у себя отдельные части этой методологии с разной степенью успешности. У кого-то лучше получается, у кого-то нет. Аналогично с DDD - отдельные команды пытаются внедрять отдельные элементы этого подхода. У кого-то получается лучше, у кого-то хуже. Где-то он нужен, где-то нет. Так и живём 🤷‍♂️

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

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

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

описание логики по классическому (мы тут в Симфони) шаблону построения проекта с анемичными сущносями дял 15 юзкесов — очень сложно и трудно и запутанно и чревато большими ошибками, низкой выразительностью

“конкретно — код станет проще и понятнее” - выше уже отвечал ^