AutoMapper развязывает домен от сущности и за ее пределами

Question

Я пытаюсь отделить свой домен от объекта и решил использовать AutoMapper для выполнения некоторых из этих задач. Возможно, это открытый вопрос, но мне интересно, как люди поступят так, чтобы отделить эти слои друг от друга. Например, у меня есть следующее:

public class A //Entity
{
    public int Id { get; set; }

    public string Name { get; set; }
}

public class B //Domain
{
    public string Name { get; set; }
}

Мне интересно, действительно ли разделение этих двух значений означало бы не представление идентификатора свойства обратно в домен? По сути, мой доменный объект будет использоваться пользовательским интерфейсом (уровень MVC), и является ли "правильным", чтобы пользовательский интерфейс имел концепцию идентификатора, имея возможность манипулировать и изменять его?

Заранее спасибо, ДС.

Answer 1

ID также является концепцией DDD, известной как идентификатор объекта. Если объект домена не имеет идентификатора, ваш пользовательский интерфейс и приложение не смогут ими манипулировать.

Например, я хочу изменить имя контакта для бронирования для заказа с trackingId[123]. UI нужен идентификатор для получения заказа. Объект домена Order затем восстанавливается путем сопоставления персистентной сущности заказа (сопоставления всех полей, кроме id). Последнее, что нужно сохранить - сохранить порядок (сопоставить домен с сущностью, но идентификатор потерян), как я могу решить, какой постоянный объект порядка должен быть обновлен, если в объекте Order нет идентификатора?

Таким образом, ответ на вопрос "Мне интересно, действительно ли разделение этих двух элементов означало бы не представлять идентификатор свойства обратно в домен?" нет.

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

create table t_order {
    tracking_id varchar2(255) pk,
    //other fields
};

create table t_order_booking_contact {
     tracking_id varchar2(255) pk,
     name varchar2(255),
     //other fields
}

Но по некоторым причинам BookingContact в модели домена является ценным объектом (идентификатор не требуется). В этом случае trackingId в персистентной модели BookingContact может быть пропущен, а маппер и персистентный компонент могут использовать вместо него trackingId в персистентной модели Order.

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

Answer 2

Вы знаете, у домена тоже есть объекты... Вы хотите, чтобы он был отделен от всего остального (persistenec, UI и т. Д.).

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

Правильно ли для пользовательского интерфейса иметь понятие идентификатора, способного манипулировать и изменять его?

Для пользовательского интерфейса правильно иметь ЛЮБУЮ информацию, необходимую для его работы. Тем не менее, пользовательский интерфейс не должен напрямую изменять модель домена. Домен изменяется в соответствии с вариантами использования (обычно реализуемыми в службах / обработчиках команд), и в 99,99% случаев я не знаю, почему вы захотите изменить идентификатор объекта домена.