@ bojanv55 Вы можете использовать ванильный объект Date в вашем DTO, если хотите. DTO не должен быть плоским. Все это связано с созданием интерфейса из DTO для отделения внешней части домена от внутренней части домена. Агрегаты, сущности, объекты значений находятся внутри домена, а команды и события являются частью интерфейса домена. Таким образом, внешний мир не будет зависеть от внутреннего (агрегаты, сущности, VO), только от интерфейса (DTO). Вы следуете той же концепции в меньшем масштабе, определяя интерфейсы и классы ...
тим, у нас есть архитектура, основанная на CQRS, с такими компонентами, как команды, модель домена, события домена, DTO модели чтения модели.
Конечно, мы можем использовать объекты-значения в нашей доменной модели. Мой вопрос, должны ли они также использоваться в:
Я не видел примеров использования Value Objects (VO) в компонентах, упомянутых выше. Вместо этого используются примитивные типы. Может быть, это просто упрощенные примеры. В конце концов, мое понимание использования ВО в DDD заключается в том, что они действуют как клей для всего приложения.
Моя мотивация:
Команды.
Допустим, пользователь отправляет форму, которая содержит поля адреса. У нас есть объект значения адреса, чтобы представить эту концепцию. При построении команды в клиенте мы должны все равно проверять вводимые пользователем данные, и, когда они правильно сформированы, мы можем сразу создать объект Address и инициализировать Command с ним. Я не вижу необходимости делегировать создание объекта Address обработчику команд.
Доменные события.
Модель предметной области уже работает в терминах объектов-значений, поэтому, публикуя события с VO вместо преобразования их в примитивные типы, мы можем избежать некоторого кода отображения. Я почти уверен, что в этом случае можно использовать VO.
DTOS.
Если наши DTO на стороне запроса могут содержать объекты-значения, это обеспечивает большую гибкость. Например, если у нас есть объект Money, мы можем выбрать, отображать ли его в евро или долларах США, не нужно менять модель чтения.