Home/ Questions/Q 1087169
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T22:54:16+00:00

In the context of DDD setters on a domain model are a code smell.

  • 0

In the context of DDD setters on a domain model are a code smell.
They should be avoided for the simple reason that they are not really part of the domain. There are no nouns in it that a Domain Expert may understand and changes to the data should go through specific methods instead.

Example:

customer.StreetName = ...
customer.City = ...

While the right way to do that would be to have a customer.ChangeAddress method that could then publish an event etc etc.. At least from my understanding this is all sound theory and I can totally understand why setters in a domain model are not really desireable.

BUT:
Without setters on your domain model, those methods get pretty hard to test.

How do I get a Customer instance to run my tests against if I can’t construct one without having either a big-ass constructor that takes in ALL arguments, or do some reflection magic? I use NHibernate in the backend so NHibernate already does some reflection magic to populate these fields in the first place.

But it feels really bad to have a ctor with 10 arguments.. (And the same would be true for a factory method).

Any advice on this?

greetings Daniel

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    In classic (non-CQRS) DDD it is a good practice to factor out all the data to Value Objects so that your entities are reduced to their primary function: maintaining identity.

    In you example Customer should reference an Address ValueObject and have a ChengeAddress method which would should be as simple as:

    public void ChangeAddress(Address address)
{
   //Consistency rules are here
   _address = address;
}

    Try to move as much logic as you can from your entities to your value objects. They are inherently more testable since good value object is small and immutable. You use a constructor to instantiate VO in a given state and exercise it (usually by invoking a method which returns another, transformed, VO instance).

    Last but not least, from my experience I can say that if testing your domain model requires additional infrastructure (like reflection or any other tool), you’re doing it wrong (by introducing unnecessary coupling).

    • 0