Доменно-ориентированный дизайн - наследование в ValueObjects

Question

User <AggregateRoot>{
  name: String;
  paymentType: PaymentType;
}

PaymentType <ValueObject> {
  //Common attributes
}

1. Может ли указанный выше PaymentType (ValueObject) быть унаследован этими ValueObjects (подклассами) - Credit, Ca sh, Check?
2. Существует инвариант домена, который говорит: «Пользователь может иметь только один тип PaymentType. Должно ли это go в User (Aggregate Root) или PaymentType (ValueObject)?

Answer 1

Может ли указанный выше PaymentType (ValueObject) быть унаследован этими ValueObjects (подклассами) - Credit, Ca sh, Check?

Возможно. Наследование - это в основном деталь реализации.

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

Скотт Влашин приводит пример типа объединения PaymentMethod в своей области моделирования сделал функциональную колоду слайдов. В его серии блогов, посвященной проектированию с типами , этот метод более подробно описан на других примерах.

Существует инвариант домена, который гласит: «Пользователь может иметь только один тип оплаты за раз. Должно ли это go в User (Aggregate Root) или PaymentType (ValueObject)?

Это зависит. Код для принятия решения о том, какие переходы между состояниями разрешены, обычно переходит к объекту, которому принадлежит состояние (в этом примере - к пользователю). Как мы представляем состояние, фактические структуры данных и т. Д., Часто живут в объектах-значениях.

Шаблоны моделирования, описанные в главе 5 (сущности, объекты-значения) и главе 6 (агрегаты, репозитории) - это просто шаблоны. Никаких призов за наиболее совершенное применение этих шаблонов не присуждается. Основная цель при реализации модели предметной области остается прежней: создание дизайна кода, который можно плавно изменять в соответствии с меняющимися потребностями предметной области.