Я прям сходу с первых строчек скажу)
"При разработке приложений, особенно по принципу доменных моделей"
Тебе надо справочник терминов сделать и перелинковку как на википедии. Я например не понимаю смысла фразы "доменная модель".
Но корни не от сюда, а из наших холиварах, где один из камней преткновения это разное понимание терминологии.


_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Вообще это документация, сухая информация, а не курсы. Курсы у меня отдельно, там подробности.

Щас я небольшой ликбез тогда проведу.

На сегодняшний день можно выделить три основных принципа построения архитектур (я не говорю о таких редких изысках, как CQRS и иже с ними).

1. Монолит - самая распространенная.
2. Анемичные модели - не популярная (а зря, на мой вкус)), иногда даже причисляемая к bad practices
3. DDD, или доменные модели - самая продвинутая на сегодня среди махровых адептов ООП.

Монолит, это когда в классах/объектах намешано всего чего попало: и данные, и обработка, и зависимости. Все это сдобрено кучей паттернов, часто вовсе не к месту, и пронизано насквозь, как шампуром, каким-нибудь диким DIC.

Допустим класс новостей (ты любишь приводить в пример) получает данные из базы, разбирает их, обрабатывает и передает по цепочке куда-нибудь на вьюшку. И так все остальное.

Важно то, что они передает информацию в виде данных примитивных типов. Строк, чисел, максимум массивов.

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

Две следующие уже ближе к чистому ООП, по нарастающей. Потому что они оперируют не примитивами, а сущностями.

Архитектура с анемичными моделями предполагает, что уровень приложения делится на два больших слоя. Сами модели и слой сервисов. Модели при такой архитектуре, за редким исключением, не содержат логики, содержат одни данные. Это может быть прослойкой между сервисами и РСУБД. Их задача хранить и изменять состояния. Сервисы же наоборот, почти никогда не хранят состояний, а содержат всю бизнес-логику. Они получают данные в виде объектов и обрабатывают их. Такая архитектура тоже не далеко ушла от процедурного кода, так как чаще всего построена на CRUD запросах.

Ну и DDD, доменная модель. Тут вообще почти все построено на объектах. Практикуются жирные (или благозвучнее - богатые) модели. То есть они содержат бизнес-логику и хранят состояния. Принципиальное отличие от первых двух в том, что слой сервисов тут довольно тонкий, вся тусовка в моделях. В DDD они описываются сущностями, объект-значениями (VO) и транспортными объектами (DTO). Сущность и VO отличаются тем, что сущность уникальна. Имеет собственный идентификатор, как id строки в таблице РСУБД. А VO это общие данные, более абстрактные. Они оба могут должны иметь логику и свои бизнес-правила. DTO не имеет логики, это объекты для чистой передачи данных.

В DDD сущность создается единожды, как строка в таблице базы данных. Она не рождается при запуске скрипта, а восстанавливается из хранилища. А при завершении складывается обратно.

На коде примерно так, чтобы было понятнее:
Имеем класс сущности юзера:

class User
{
    public $id;
    public $username;
    
    public function __toString()
    {
        return 'id='.$this->id .' name:'. $this->username;
    }
}

В классическом (монолитном) исполнении инициализация объекта будет происходить как то так:

$user = new User;
$user->id = 1;
$user->username = 'John';

echo $user; // id=1 name:John 

И совершенно не важно, затолкаешь ты объект в контейнер, контейнер в объект, передашь зависимостью или еще чего. Потому что он изначально не имеет идентификации. ID нужно сначала где то взять, потом уже присвоить объекту примитивными данными.

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

// Это хранилище
$repository = [1 => 'O:4:"User":2:{s:2:"id";i:1;s:8:"username";s:4:"John";}'];

// Никакого new, ничего не присваиваем, просто получаем объект из хранилища
$john = unserialize($repository[1]);
echo $john; // id=1 name:John

Оперировать сущностями при проектировании на много проще, так как они описывают состояния и поведения, максимально приближенно к реальности. Потому и придуман термин Ubiquitous Language. Язык, понятный разным разработчким и даже заказчикам. Потому что, если заказчику нужно на сайте сделать систему заказов (каламбур), сущность заказа будет называться Order, и будет содержать поля "наименование", "количество", "цена" и т.д. И может допустим содержать метод подсчета дней в пути. Или расчета скидки. Вобщем всех бизнес-правил, относящихся к заказу. Всем всё понятно, рисуем UML.

Когда заказ сформирован, объект сущности создан, айдишнек присвоен, всё. Этот заказ будет жить в виде объекта, пока не исполнится и не удалится из репозитория.

Это все очень круто, но по такой схеме довольно сложно работать с реляционными базами данных. Нужны мощные ORM. Со своим синтаксисом, мутью, тоской и нагрузками. Либо мигрировать на базы NoSQL. Со всеми вытекающими.

Так что и тут не все гладко. Ну не придумали пока идеальной схемы. :)


Теперь понятно, что такое доменная модель (DDD)?

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

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

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