Вот тут уже стало понятнее, т.е. Агрегат это своего рода фасад, но при этом имеющий собственный идентификатор, например User.id
Всё объекты внутри агрегата это либо сущности (в случае если нам нужна их идентификация по ID, либо VO, если мы их идентифицируем только по значениям полей. При этом в пределах агрегата Сущности могут быть изменяемыми, а VO нет (что логично ибо как что-то изменить если не можешь его идентифицировать).
Это понятно.
Теперь вот мне не ясно, как писать классы для такой системы.
Мы все привыкли мыслить классами, в этом случае придется немного мыслить по-другому, но не отходя далеко от реализации, поэтому мы сначала создаем классы, которые будут представлять из себя VO, потом из них под требование бизнеса меняем классы чтобы некоторые из них стали Entity (по сути просто добавляем свойство $id), и получив в итоге пару-тройку Entity и несколько VO собираем из них Агрегат, заточенный под конкретную задачу, например редактирование того же самого юзера, так?
А если в каких-то случаях VO должен быть изменяем? Писать отдельную реализацию этого VO?
Вот еще хороший материал по теме https://izif.com/uploads/ddd-in-php-sample.pdf

_____________
программирование - инструмент для решения конкретных задач, любая попытка спроектировать что-то универсальное приведет к провалу.©paul85
В любом случае тебе прийдётся пройти путь изобретения велосипеда, который прошли другие, только причиной твоего изобретения будет непонимание принципов работы велосипеда изобретённого другими людьми.©SlavaFr
jQuery это попытка использовать АН-225 для перевозки зубочистки

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

_____________
программирование - инструмент для решения конкретных задач, любая попытка спроектировать что-то универсальное приведет к провалу.©paul85
В любом случае тебе прийдётся пройти путь изобретения велосипеда, который прошли другие, только причиной твоего изобретения будет непонимание принципов работы велосипеда изобретённого другими людьми.©SlavaFr
jQuery это попытка использовать АН-225 для перевозки зубочистки

Для этого не нужно разбираться в дебрях космолета под названием DDD.
Фреймворконезависимость - это идеи из Чистых архитектур. Когда фрейм используется только на внешних слоях.
Можешь ознакомиться по Kristopher Wilson - The Clean Architecture in PHP
Ситуация с Laravel упрощается тем что используя Eloquent ты в новом проекте его можно оставить, т.к. он - независимая библиотека.

_____________
There never was a struggle in the soul of a good man that was not hard

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

Например в книге по тестам эти вещи так объясняются:

_____________
There never was a struggle in the soul of a good man that was not hard

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

Может быть неудачная, но суть именно такая. Первичен объект. Вот к примеру объект:

object(car)#1 (1) {
  ["model"]=>
  string(18) "Запорожец"
}

Что этот объект умеет делать? Ничего. Потому что нужен класс, тогда что то может произойти. Причем, при взаимодействии с разными классами, он может выполнять совершенно различные действия.

Допустим, если его сериализовать:

а потом использовать в разных системах:

class car
{
    public function run()
    {
        echo 'go!';
    }
    
}

$car = 'O:3:"car":1:{s:5:"model";s:18:"Запорожец";}';
$car = unserialize($car);

$car->run();

а в другой так:

class car
{
    public function drive()
    {
        echo "let's go!";
    }
    
}

$car = 'O:3:"car":1:{s:5:"model";s:18:"Запорожец";}';
$car = unserialize($car);

$car->drive();

ТО все отлично сработает, совершенно не взирая на то, как объект был получен. Простой инициализацией, гидрацией или еще как.

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

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

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.