Entity vs Value Object DDD?

Question

[Расул]

Всем привет! Разрабатываю приложение на asp.core для работы с заявками. Пытаюсь применить DDD.
Возникает неуверенность в некоторых решениях. Попробую коротко описать сущности.

Есть два основных агрегата `User` и `Ticket`
```
```

public class User
    {
        public UserId Id { get; private set; }
        public FullName FullName { get; private set; }
        public DateTime BirthDate { get; private set; }
        public Group Group { get; private set; }
        ...
    }

    public class Ticket
    {
        public TicketId { get; private set; }
        public Group Group { get; private set; }
        ...
    }

`Group` это справочник который хранится в другой БД и изменятся другим приложением. Его я сделал как Entity, содержит Id и Name. В `User` это поле определяет к какой группе относится пользователь. В `Ticket` определят на какую группу назначена заявка. В `Ticket` таких справочников несколько.

Возникли вопросы:

**1.**Правильно ли что `Group` это Entity? Думал сделать его и другие справочники как ValueObject, но читал что объекты значения не принято хранить в отдельных таблицах. И мне необходимо в агрегатах, фактически (в БД) хранить только GroupId, чтобы после изменения в справочнике `Group`, в агрегатах получать измененное значение.

**2.**Если `Group` все таки Entity, то как мне ссылаться на нее в двух агрегатах? Выносить ее в отдельный агрегат, кажется неправильным. Как вариант, думал для `Ticket` создать Entity `TicketGroup`, но по факту через репозиторий возвращать одни и те же данный с одной таблицы

Answer 1

[Максим]

1. Отличие VO от Entity это то, то её можно идентифицировать по Id. Так же структура VO не меняется с течением времени. Например, VO Email где бы то не был будет одинаковым и его логика долго не поменяется.

2. Тут зависит от того как вы используете эти Group. Если вам где-то в вашем приложении эти группы нужны, то их лучше создать как отдельную сущность/агрегат. Но можно и сделать их VO в сущности Ticket и хранить только ID Group, либо непосредственно название группы. Все зависит от того как вы работаете с этим в вашем контексте. Например, в контексте справочников Group может быть сущностью и это нормально. А в контексте Ticket можно хранить только ID или само значение.

Comments

[Расул]

Спасибо Максим! В приложении используется именно Id, например в условии, отображать заявку только пользователям с таким же GroupId. Но для отображения, в списке заявок или деталях, мне нужно название. Поэтому в агрегатах я храню ссылку на Group. А если вынести Group в агрегат, то насколько я знаю, хранить в других агрегатах мы можем только GroupId.

[Максим]

RaSul909, название вам нужно на frontend части для отображения. Поэтому вы спокойно по id сможете запросить все названия ))

[Расул]

Максим, Т. е. в слое Application, например в UseCase, нужно будет преобразовать доменную сущность в DTO (где будут подгружены значения по id из справочников), а потом отправить в контроллер? В контроллере (слой Api) вызываю UseCase и, либо сразу передаю на фронт DTO, либо преобразую во ViewModel, которая хранится в этом же слое?

[Максим]

RaSul909, вариантов несколько для получения дополнительных данных:
1. В контроллере с помощью Fetcher
2. На стороне фронтенда разными api запросами
3. Getaway например, GraphQL

[Расул]

Максим, Создавать DTO в Application не нужно? Передаем доменную сущность в контроллер, а там подтягиваем данные? Тогда надо получить доступ к хранилищу через репозиторий. А это хорошо, делать запросы к БД с API слоя ? Насколько я понимаю, в котроллер нужно передать все нужные данные или я ошибаюсь? Спасибо)

[Максим]

RaSul909, если следовать CQRS, DTO нужно либо для запроса (Query), либо для модификации (UseCase, Command). Ну и из Query можно возвращать данные не в массиве, а в DTO, но тут уже вам решать как поступить

Что касается того где собирать данные для выдачи в API. Следует это делать так называемом Query (ReadRepositofy, Fetcher). С помощью Join вы собираете данные, либо подгружаете данные через какого-то клиента из другого сервиса, после этого данные можно отдавать в контроллер Api.

Read Repository отличается от Domain Repository тем, что он работает только на чтение данных для frontend. Он и запросы использует без какой-то ORM, а хоть на чистом SQL.

Пример на php

interface VideoReadRepository
{
    public function allByAuthor(string $authorId): array;

    public function find(string $authorId, string $id): ?Video;
}

[Расул]

Максим, Спасибо большое Максим! Наверное, в моем случае, по крайней мере пока, Group, будет Value Object, где будет хранится только id, т.е. не Group а GroupId. В логике, в условиях я опираюсь только на Id. А значение я буду получать из хранилища для отображения, одним из способов, которые вы описали. И хотелось бы уточнить )). Когда вы спрашивали, нужны ли эти группы в приложении, вы имели ввиду: веду ли я работу отдельно с ними (добавление, удаление, редактирование, т. е запуск отдельного бизнес процесса), или же они нужны только для описания сущности и возможно в зависимости от их значения, они могут повлиять на бизнес процесс в этой сущности?

[Максим]

Расул, практически так, то есть нужно смотреть на сколько будет критично если сторонний сервис отпадёт Если у вас ничего в работе не поменяется, то можно забыть об этом. Если же поменяется, то придётся копировать данные из того сервиса в ваш. Например при добавлении id вы идёте в тот сервис и кладёте в свой сервис эти группы. Так же если вам понадобиться например информация о группе при отсылке почты или уведомления, где не особо допускается отображать id в случае отказа сервиса или «группа не найдена». То есть если логика и приложение не перестаёт работать, а имя нужно только на стороне фронта, то об этом можно не париться. Вы просто можете написать «группа не доступна».