Мой вопрос прост, скажем, у меня есть Car
сущность, которая имеет Number
объект значения и Truck
субъект, который имеет Number
объект стоимости также,
сделать это означает, что у меня есть один объект значения в моем приложении с именем Number
для обеих сущностей в качестве объекта общего значения?
или это до того, что делают Number
действителен для каждого субъекта?
Объекты-значения по определению являются неизменными и должны иметь возможность безопасного совместного использования. У него нет идентичности. Я могу порекомендовать книгу Эрика Эванса (Driven Design), основанную на предметной области (глава 5 подробно объясняет эти концепции). Также, пожалуйста, смотрите статья Мартин Фаулер
«сделать это означает, что у меня есть один объект значения в моем приложении с именем Number for
обе сущности как объект общего значения? «
Number
может быть общая концепция если они оба представляют одно и то же в соответствии с вашим вездесущим языком. Если они этого не делают, то требуется различие, такое как CarNumber
а также TruckNumber
(например, оба требуют другого формата).
Одно замечание: одного контекста, если он хорошо определен, обычно достаточно, чтобы избежать перегрузки терминов, поэтому вы редко будете сталкиваться с такими вещами, как UserAccount
а также BankAccount
в ограниченном контексте (BC), и если вы делаете, то ваши границы BC, скорее всего, неверны.
Тем не менее, я считаю, что есть что-то немного другое Number
, Поскольку это хорошо известная математическая концепция и весьма вероятно, что в вашей области будут использоваться некоторые математические числа, я бы предложил немного более наглядно, чтобы избежать путаницы, возможно, VehiculeNumber
?
Во-первых, объекты Value, как и большинство реализаций DDD, должны быть смоделированы так, чтобы соответствовать некоторой части вездесущего языка вашего домена.
Когда создавать объект значения? В книге Implementing Domain Driven Design
Вон Вернон дает эти характеристики объекта значения
Первый бюллетень означает, что ВО должен измерять, количественно или описывать предмет в домене.
Далее, он должен быть неизменным и не должен иметь методов изменения состояния. Это также относится и к любым объектам внутри ВО, они тоже никогда не должны изменяться, если ВО их использует.
Двигаясь дальше, VO должен быть завершен после строительства. Это означает, что все его атрибуты и свойства, которые ему нужны, должны быть в допустимом состоянии. Пример: цена ВО должна установить оба currency
а также amount
свойства с правильными значениями в конструкторе.
Тиражирование. Это означает, что ВО может быть заменено другим ВО того же типа. Если ваш VO может установить currency
к йене, а не к доллару, тогда это может стать проблемой, если позже попытаться заменить VO, потому что вы хотите изменить (заменить) amount
за price
,
Пример: сущность принимает VO Price
который имеет currency
доллара и amount
100 000 Если бы мы могли построить новый ВО такого же типа с currency
иены и ап amount
из 200 000, то это ВО не может быть заменяемым. Конечно, это будет зависеть от вашего домена, но если организация намерена просто заменить денежную стоимость VO, то, возможно, было бы лучше иметь отдельный DollarVO
а также YenVO
чтобы избежать создания ВО с несоответствием свойств импеданса.
Сравнение: VO должны быть сопоставимы с другими экземплярами VO того же типа. Если ВО может быть построен с currency
собственности, но в других случаях это не так, то это потенциально может нарушить сопоставимость. IE. Вы должны иметь возможность взять два экземпляра одного и того же VO и сравнить их свойства, проверяя только разные значения этих свойств. Если свойство отсутствует, то сравнение не выполняется по неправильной причине.
Последний принцип является неотъемлемой частью неизменности. Если ты собираешься дать методы В.О., то убедись, что они ничего не меняют.