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

PaymentType <ValueObject> {
  //Common attributes
}
  1. Can the above PaymentType(ValueObject) be inherited by these ValueObjects(Subclasses) - Credit, Cash, Cheque ?
  2. There is a domain invariant that says, User can have one PaymentType at a time. Should this go into the User(AggregateRoot) or PaymentType(ValueObject) ?
Sneh
  • 413
  • 1
  • 5
  • 18

1 Answers1

1

Can the above PaymentType(ValueObject) be inherited by these ValueObjects(Subclasses) - Credit, Cash, Cheque ?

Maybe. Inheritance is largely an implementation detail.

But it's not clear to me that's the question you are really asking. Your example looks a bit like trying to design a "union type", which is to say a handle that you can use to match different patterns.

Scott Wlaschin has an example of a PaymentMethod union type in his domain modeling made functional slide deck. His blog series on designing with types describes the technique in more detail using other examples.

There is a domain invariant that says, User can have one PaymentType at a time. Should this go into the User(AggregateRoot) or PaymentType(ValueObject) ?

It depends. The code for deciding which state transitions are permitted normally goes into the thing that owns the state (in this example, the User). How we represent state, the actual data structures and so on, often live in Value Objects.

The modeling patterns described in chapter 5 (entities, value objects) and chapter 6 (aggregates, repositories) are just patterns. There are no prizes awarded for applying those patterns most perfectly. The main goal in implementing the domain model is still the same: to produce code designs that can be changed smoothly to match the changing needs of the domain.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91
  • Those 2 links are useful, thanks for sharing.Do you have any alternative solution instead of creating union types? Also, which book you are referring here(Chapter 5 and Chapter 6)? – Sneh Jun 16 '20 at 14:03
  • Eric Evans, Domain-Driven Design (2003). – VoiceOfUnreason Jun 16 '20 at 14:23
  • Thanks @VoiceOfUnreason. Do you have any alternative solution instead of creating union types? – Sneh Jun 16 '20 at 15:05