CODEWITHSUNDEEP
domain-driven-design
Robert
Robert

Reputation: 3543

DDD Value objects

Quoting Evans blue book

It may surprise you to learn that we should strive to model using Value Objects instead of Entities wherever possible. Even when a domain concept must be modeled as an Entity, the Entity’s design should be biased toward serving as a Value container rather than a child Entity container. That advice is not based on an arbitrary preference. Value types that measure, quantify, or describe things are easier to create, test, use, optimize, and maintain.

To put it in my context, I have

Every invoice has it's Issuer. Should i treat this as a Invoice->Issuer relation via ID, or it's a better practice to treat this as a Value Object with a reference to Issuer, or to treat this issuer simply as a value object created from Issuer AR

So in this case it would be

1.

  Invoice
    -InvoiceId
    -IssuerId

VS 

Invoice
-InvoiceId
-InvoiceIssuer
  -IssuerId
  -FullName

VS 

Invoice
 -InvoiceId
  -InvoiceIssuer
   - Fullname

I am leaning torwards solution number 2, becasue if the Issuer's name ever changes for some reason, I will still have a name of the Issuer at the time of invoice creation, and a reference to Issuer who changed his name.

Logic behind this is if I try to print an old invoice, after the Issuer changed his name, I will still have invoice in it's old state, since it was printed like that in the first place, but if I will still be able to find all Invoices by that Issuer, even he changed his name.

Is creation Value Objects with a reference to another entity by ID valid approach, or I am doing something wrong in this case?

Upvotes: 2

Views: 170

Answers (1)

plalx
plalx

Reputation: 43718

"am leaning torwards solution number 2, becasue if the Issuer's name ever changes for some reason, I will still have a name of the Issuer at the time of invoice creation, and a reference to Issuer who changed his name."

You already answered the question by yourself. The only model that fits the above requirements is #2.

There are definitely modeling best practices that you can strive to follow (favor value objects, design small aggregates, etc.), but at the end DDD is about crafting domain-specific models and such a model can only be criticized and only has value in the context of it's problem domain.

When you seek to validate your model, focus on the business behaviors & invariants first.

Upvotes: 3

Related Questions