Значения объектов в CQRS - где использовать

Question

Допустим, у нас есть архитектура, вдохновленная CQRS, с такими компонентами, как команды, доменная модель, доменные события, чтение модели DTOS.
Конечно, мы можем использовать объекты значения в нашей модели домена. Мой вопрос: если они также будут использованы в:

1. Команды
2. События
3. DTOS

Я не видел никаких примеров, где объекты значения (VO) используются в компонентах, упомянутых выше. Вместо этого используются примитивные типы. Может быть, это просто упрощенные примеры. В конце концов, мое понимание использования VOS в DDD заключается в том, что они действуют как клей для всего приложения.

Моя мотивация:

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

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

DTOS.
Если наши DTO на стороне запроса могут содержать объекты значения, это позволяет получить большую гибкость. Например, если у нас есть Money Object, мы можем выбрать, отображать его в EUR или USD, нет необходимости менять модель чтения.

Answer 1

Хорошо, я передумал. Я пытался справиться с VOS в последнее время и после просмотра этого http://www.infoq.com/presentations/value-objects-dan-bergh-johnsson Это уточнило пару вещей для меня.

Команды и события - это сообщения (а не объекты, объекты являются данными + поведение), в некоторых отношениях, как DTO, они сообщают данные о событии, и сами они не инкапсулируют поведение.

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

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

Перефразируя Орен (хотя он имел в виду Nhibernate и WCF) «Не отправляйте свой домен через проволоку».http://ayende.com/blog/archive/2009/05/14/the-pripper-pattern.aspx

Если вы хотите передать объект Value, то я предлагаю пропустить необходимые атрибуты, необходимые для повторного конструирования VO внутри них.

Исходный текст (для потомков):

Если вы спрашиваете, могут ли объекты значений быть переданы моделью домена на события или передаваемые командами, я на самом деле не вижу огромной проблемы с первым, хотя последний может нарушить некоторые правила совокупного корня - это «Владелец» ценностей.

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

Чтение главы из DDD по совокупному корнеу модели довольно хорошо объясняет объекты и объекты ценности и стоит прочитать несколько раз.

Answer 2

Я говорю, что это плохая идея.

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

Представьте, что вы делаете событие, содержащее Vo. Изменение в вашем домене требует, чтобы вы изменили этот Vo. Теперь вы попали в угол, где ваше мероприятие также принужденный Чтобы изменить, то же самое для любых команд или DTO, от которой это часть.

Этого следует избегать.

Используйте DTO и/или примитивы. Карту их (Automapper делает это сделкой 1 линии).

Answer 3

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

Answer 4

Согласно с Чистый код Ваши DTO - это структуры данных (просто для добавления другого термина), в то время как объекты значения являются объектами. Разница, которую объекты могут иметь поведение. Смешивание структур данных с объектами, как правило, очень плохая идея, потому что будет трудно поддерживать гибрид, который вы получаете.

Я не чувствую себя правым, чтобы поставить объекты ценности в DTOS с точки зрения архитектуры. Объекты значения находятся внутри модели домена, в то время как упомянутые вами DTOS определяют интерфейс модели. Обычно мы строим интерфейс, чтобы отделить внешний мир изнутри чего -то. Таким образом, в текущем случае мы добавили DTOS, чтобы отделить внешний мир от объектов Value (и других вещей, связанных с моделью). После этого добавления значения объекты к интерфейсу безумно.

Так что вы еще не выполнили это решение, потому что это анти-паттерн.