Стандартные типы значений как ValueObjects в DDD?
Имеет ли смысл при моделировании домена с сущностями и объектами значений также создавать «базовые» типы значений в качестве хорошо определенных объектов значений?
Например, у меня может быть объект значения EmailAddress или ProductName. Но как насчет String как объекта значения? Противоречит ли это какому-либо известному принципу по какой-либо уважительной причине? Что мне действительно интересно, так это то, должен ли я / мог бы определить все возможные значения свойств как объекты значений, включая string, bool, int и т. д. Это неправильно или просто слишком далеко? Почему-то мне кажется, что я предпочел бы по-настоящему откровенно описывать любую «вещь», являющуюся какой-либо ценностью, и не оставлять ничего открытым для интерпретации. Как вы думаете? Что об этом говорят гуру?
А на Справка я наткнулся:
It's often a good idea to replace common primitives, such as strings, with appropriate value objects. While I can represent a telephone number as a string, turning into a telephone number object makes variables and parameters more explicit (with type checking when the language supports it), a natural focus for validation, and avoiding inapplicable behaviors (such as doing arithmetic on integer id numbers).
Ответы 2
Объекты значений в DDD - отличная вещь, они неизменяемы, поэтому их можно безопасно передавать, они охватывают данные и их поведение в хорошем режиме ООП (если вы используете ООП). Они также делают неявное явным и обеспечивают строгую типизацию.
Если вам нужна какая-либо из вышеперечисленных функций, вы должны создать объект Value (класс, компонент ... все, что существует на вашем языке) для любого свойства, которое в нем нуждается.
Если, однако, ничего из вышеперечисленного вам не нужно, не следует этого делать. Вы не создаете новый класс только потому, что так говорит какой-то «гуру», например every property of an Aggregate should be a Value object.
Самый важный аспект заключается в том, что если у вас есть какое-то свойство, которое имеет данные, а также поведение, и вам нужно создать для него класс, тогда этот класс должен быть объектом Value, в частности, он должен быть неизменяемым (исключая сущности).
«Что бы об этом подумал эксперт по предметной области?» - если к вам не привязано поведение, то эксперту по предметной области это все равно
". И что эта UInt64-вещь транслируется, например, в javascript или в любой другой среде, кроме .NET?" - это преобразование касается инфраструктуры, а не домена. Вы можете создать несколько достаточно умных языковых переводчиков.
"Я имею в виду, это подходящая модель предметной области в любое время?" - вы не создаете что-то только потому, что вам это может понадобиться. ЯГНИ. Если вам это понадобится, вы можете провести рефакторинг.
В случае с UInt64, не является ли неявным поведением, по крайней мере, то, что значение, вероятно, должно быть больше 0? Разве это не интересует специалиста по предметной области?
Если у вас есть поведение, вы создаете объект Value, как я написал в своем ответе.
Но все же мне трудно понять, когда значение не имеет никакого поведения?
если ваш объект значения будет иметь одно свойство и никаких других методов, кроме простого конструктора и метода, возвращающего это свойство, это означает, что он не имеет никакого поведения и бесполезно создавать этот объект значения. Если вы можете разместить некоторые методы внутри объекта значения, это означает, что у него есть поведение.
Я утверждаю, что ограничения на значения также мотивируют наличие явных типов значений (не только поведения). Значение без ограничения - это любое значение. Кроме того, если у типа значения есть общедоступные свойства, тогда они также должны иметь явные типы объектов-значений.
@AndreasZita Поведение - это методы, которые работают с этими данными, включая валидаторы; встроенные преобразователи из одних единиц в другие (из метров в дюймы), компараторы и т. д .; геттеры - это не поведение.
Возможно, вам нужно прочитать технический документ «Из ямы со смолой» или посмотреть разговор Ромеу Моура на встрече DDD Norway.
Примитивные типы - это нет, помогающий сделать неявный явным. По умолчанию это скрытый. Это делает систему бесконечно сложной, поскольку количество состояний такой системы неопределенно.
Я согласен, что занятия могут показаться обузой. Вы действительно можете избегать использования объектов-значений, но тогда вам нужно признать, что ваш вездесущий язык больше не является повсеместным. Вездесущий означает, что язык используется везде, включая код. Вы не можете сказать «название продукта» ожидаемому домену, а затем вернуться к своему коду и увидеть «строку». Это также не передает язык вашей предметной области другим разработчикам.
Ив Рейнхаут представил отличный разговор об этих вещах на прошлогодней конференции KanDDDinsly, которую рекомендовал посмотреть.
Лично я действительно ожидаю, что новые возможности языка OO, такие как предлагаемые типы записей C#, сделают все так же просто, как и в функциональных языках. Кстати, чтение о системе типов на функциональном языке дает много отличных идей и для объектно-ориентированных программистов. Например, F# для развлечения и прибыли имеет этот отличная статья о типах и DDD. Кстати, начинается с поиска string, какое совпадение ...
Спасибо за ссылки!
Но если в моем домене будет свойство типа "System.UInt64". Что об этом подумает эксперт в предметной области? Должен ли он знать, что это такое? И что эта UInt64-вещь переводит, например, в javascript или любую другую среду, кроме .NET? Я имею в виду, что это подходящая модель предметной области в любое время? Или я просто придираюсь к мелочам?