Entities Shouldn't Have Getters

This post follows on from Entities Shouldn't Have Setters.

The principle of Tell, Don't Ask states that one of the consequences of an object having getters is that there is often the temptation for another object to read the values from the getters, make a decision based on those values, and then update the object using the setters (as covered in the last post). A more Object-Oriented design would be to simply 'tell' the object what you want to do, and allow it to make the decision based on its internal state.

However, as acknowledged by Martin Fowler, it is very often the case that we need to display the state of an entity to a UI. However, the use of getters in this case can be avoided by displaying a persistent view model instead of the entity. The persistent view model is what is displayed to the user, and it is updated whenever the entity changes. This is the basic principle behind CQRS.

Imagine our Post object from our blog example in the last post. If we were to have an Edit use case for this, the traditional series of events might be:

• Call Edit on the Post entity with the new content of the post.
• Save the Post entity.
• Load the new Post entity from the database.
• Display the various properties of the Post entity by accessing its getters.

With CQRS, it might look more like this:

• Call Edit on the Post entity with the new content of the post.
• The Post entity raises a PostEdited domain event containing the new values.
• The application layer handles the domain event, saves the entity and publishes an event on NServiceBus containing the new values.
• The read model subscribes to this event, and updates the persistent read model accordingly.
• When the UI is refreshed, it displays the properties of the persistent view model by accessing its getters.

This way we have avoided using the getters of the entity.

For more information on publishing domain events, read This post by Udi Dahan.

So I should immediately stop using getters and setters on my entities?

No, this is somewhat ideological. The first issue I have come across is that it is often desirable to use getters and setters when testing. Getters are useful for the asserts, and setters are useful because for many tests, we do not need to set up the whole entity. Maybe that is breaking some testing ideology, but in the real world, sometimes we need to be able to quickly set up entities without using their use cases.

And of course, CQRS is not always appropriate for every application.

So what was the point of these posts? The point is that you should understand that it can be done, and why and when you may choose to do it. This way you can apply these rules where it makes sense.

So it is unlikely I will be writing entities without getters or setters for now, but there are some rules to take from this:

• If you are calling getters or setters of an entity from another entity in your domain, you are probably doing something wrong.
• If you are calling getters or setters of an entity in your application layer you are probably doing something wrong (unless you are mapping to a DTO).
• If you are calling setters of an entity in your UI you are almost certainly doing something wrong.