> Люди  любят упрощать до нет VO в коде - у вас не ДДД

но ты ведь это сейчас и делаешь. Чего-то нет - не ддд.

Неправда. Я так не говорил. Не следует ддд не равно отсутствует ддд.

Господа архиткеторы, можете на пальцах в двух словах обьяснить отличие между ДДД и чистой архитектурой? Это подходы к решению одной и той же проблемы или это разные вообще парафии? и что лучше использовать? и вообще можно ли их сравнивать? И насколько я знаю ДДД вышел раньше чем clean arch, значит ли что он более "устаревший"? Заранее спасибо.

public function updateProfile(UpdateProfile $request)
{
     $this->db->executeUpdate(
          <<<SQL
               UPDATE user_profiles SET name=?, phone=? WHERE id=?
          SQL, 
          [$request->name, $request->phone, $request->userId]
     );

     $this->send(ProfileUpdated::forUser($request->userId);
}

чем не ДДД?)

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

Пока ддд и клиникод отсутствуют в палате мер и весов, придётся выбирать самому в зависимости от ситуации, следатвенно желательно ознакомиться с обоими двумя

"чистая архитектура" она про направления зависимостей и направлена больше на уменьшение вероятности появления каскада изменений. Для того что бы архитектура была чистой тебе нужен минимальный уровень представления откуда требования берутся (анализ потока изменений требований), иначе невозможно соблюдать все эти SRP и open/close. Но в целом именно ответа на вопрос "а как именно чего дробить" помимо слоев и инверсии зависимостей оно тебе не дает.

DDD это уже более абстрактная штука. Фактически если говорить о DDD как о методологии большинство сводят это дело к способам моделировать домен и выделять bounded contexts и поддомены. Для больших продуктов все это важно так как bounded context оч красиво ложатся на потоки изменений требований и удобны для декомпозиции продукта на кучу дев команд и вот это все. Соответственно с оптимальными границами контекстов, выделением зависимостей, вводом терминологии внутри контекста и как это все мэпится друг на дружку у тебя появляется та самая модель предметной области. Ну и вот весь процесс формирования и постоянного рефайна этой модели укладывается в DDD.

Связь с кодом тут разве что за счет conway's law

ну я реально не понимаю твой поинт. Объясни мне если "многие упрощают если нет VO то не DDD" то почему ты пристал к моему круду?

если какой-то поддомен это тупой круд это не значит что тебе не нужен DDD

@fes0r @dmitriytk благодарю

грубо говоря - смысл DDD - управление сложностью. Слои управления сложностью не дают. А разделение на контексты позволяют тебе разрезать большую систему на куски с целью держать когнетивную нагрузку одной команды на уровне с которым она справится.

но по факту они оба - это подходы к проектированию архитектуры, верно?

потому что не существует состояния "нет ДДД" как и нет "есть ДДД". Типа библии, свод правил, которые приведут к светлому будущему (это не является публичной офертой)

ну DDD скорее не напрямую. Оно скорее тебе дает инструменты за счет которых ты можешь принимать архитектурные решения. Опять же решение о том как систему раздробить на контексты по итогу сильно сказывается на том как будет организована структура проекта. Но это опять же conway law.

мол "if you developing compiler and you have 4 teams, you will end up with 4-pass compiler"

главное отличие что в чистую архитектуру ты можешь без бизнеса играться. А для DDD нужно взаимодействие с оным.

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

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

поясни мысль. То есть ты все же делаешь корреляции между тем что в коде и DDD :)

еще наброшу - тактический DDD это булшит но даже он не про код. Не говоря про стратегический

Именно что корреляцию, а не причиной следственную связь