MNW #042: Refactoring From an Anemic Domain Model To a Rich Domain Model

Read time: 6 minutes

A big thank you to our sponsors who keep this newsletter free to the reader:

Today's issue is sponsored by IcePanel. IcePanel is a collaborative C4 model modelling & diagramming tool that helps explain complex software systems. With an interactive map, you can align your software engineering & product teams on technical decisions across the business.

And by ABP Commercial. ABP Commercial is a complete web development platform built on ABP Framework, perfect for enterprise-grade ASP.NET Core based web applications. Pre-built application modules, advanced startup templates, rapid application development tooling, professional UI themes and premium support.

Is the anemic domain model an antipattern? It's a domain model without any behavior and only data properties.

Anemic domain models work great in simple applications, but they are difficult to maintain and evolve if you have rich business logic.

The important parts of your business logic and rules end up being scattered all over the application. It reduces cohesiveness and reusability, and makes adding new features more difficult.

Rich domain model attempts to solve this by encapsulating as much of the business logic as possible.

But how can you design a rich domain model?

This is a never-ending process of moving business logic into the domain and refining your domain model.

Let's see how to refactor from an anemic domain model to a rich domain model.

Working With Anemic Domain Model

To understand what working with an anemic domain model looks like, I'll use an example of handling a SendInvitationCommand.

I omitted the class and its dependencies so that we can focus on the Handle method. It loads some entities from the database, performs validation, executes the business logic, and finally persists the changes in the database and sends an email.

It already implements some good practices like using repositories and returning result objects.

However, it's working with an anemic domain model.

A few things indicating this:

Parameterless constructors
Public property setters
Exposed collections

In other words - the classes representing domain entities contain only data properties and no behavior.

The problems of an anemic domain model are:

Discoverability of operations
Potential code duplication
Lack of encapsulatinon

We'll apply a few techniques to push logic down into the domain, and try to make the model more domain-driven. I hope you'll be able to see the value and benefits this will bring.

Moving Business Logic Into The Domain

The goal is to move as much of the business logic as possible into the domain.

Let's start with the Invitation entity and defining a constructor for it. I can simplify the design by setting the Status and CreatedOnUtc properties inside the constructor. I'm also going to make it internal so that an Invitation instance can only be created within the domain.

The reason I made the Invitation constructor internal is so that I can introduce a new method on the Gathering entity. Let's call it SendInvitation and it will be responsible for instantiating a new Invitation instance and adding it to the internal collection.

Currently, the Gathering.Invitations collection is public, which means anyone can obtain a reference and modify the collection.

We don't want to allow this, so what we can do is encapsulate this collection behind a private field. This moves the responsibility for managing the _invitations collection to the Gathering class.

Here's how the Gathering class looks like now:

Moving Validation Rules Into The Domain

The next thing we can do is move the validation rules into the SendInvitation method, further enriching the domain model.

Unfortunately, this is still a bad practice because of throwing "expected" exceptions when a validation fails. If you want to use exceptions to enforce your validation rules you should at least do it right, and use specific exceptions instead of generic ones.

But it would be even better to use a result object to express validation errors.

Here's how using result objects would look like:

The benefit of this approach is we can introduce constants for possible domain errors. The catalog of domain errors will act as documentation for your domain, and make it more expressive.

Finally, here's how the Handle method looks like with all the changes so far:

If you take a closer look at the Handle method you'll notice it's doing two things:

Persisting changes to the database
Sending an email

This means it's not atomic.

There's a potential for the database transaction to complete, and the email sending to fail. Also, sending the email will slow down the method which could affect performance.

How can make this method atomic?

By sending the email in the background. It's not important for our business logic, so this is safe to do.

Expressing Side Effects With Domain Events

You can use domain events to express that something occurred in your domain that might be interesting to other components in your system.

I often use domain events to trigger actions in the background, like sending a notification or email.

Let's introduce an InvitationSentDomainEvent:

We're going to raise this domain event inside the SendInvitation method:

The goal is to remove the code responsible for sending the email from the Handle method:

We only want to worry about executing the business logic and persisting any changes to the database. Part of those changes will also be the domain event, which the system will publish in the background.

Of course, we need a respective handler for the domain event:

We achieved two things:

Handling the SendInvitationCommand is now atomic
Email is sent in the background, and can be safely retried in case of an error

Takeaway

Designing a rich domain model is a gradual process, and you can slowly evolve the domain model over time.

The first step could be making your domain model more defensive:

Hiding constructors with the internal keyword
Encapsulating collection access

The benefit is your domain models will have a fine-grained public API (methods) which act as an entry point for executing the business logic.

It's easy to test behavior when it's encapsulated in a class without having to mock external dependencies.

You can raise domain events to notify the system that something of important occurred, and any interested components can subscribe to that domain event. Domain events allow you to develop a decoupled system, where you focus on the core domain logic, and don't have to worry about the side effects.

However, this doesn't mean that every system needs a rich domain model.

You should be pragmatic and decide when the complexity is worth it.

That's all for this week.

See you next Saturday.

Whenever you're ready, there are 2 ways I can help you 🎁

If you're looking to join a community of like-minded engineers or you want to access all of the source code that I use in my YouTube videos, you can do that by becoming a Patron. Join 720+ engineers here.
Promote yourself to 23,000+ subscribers by sponsoring this newsletter (booked out 2 months)

You received this email because you subscribed to our list. You can unsubscribe at any time.

Dragise Cvetkovica 2, Niš, 18000, Serbia

complete web development platform rapid application development tooling advanced startup templates professional UI themes anemic domain model rich domain model complex software systems

MNW #042: Refactoring From an Anemic Domain Model To a Rich Domain Model

MNW #042: Refactoring From an Anemic Domain Model To a Rich Domain Model

Working With Anemic Domain Model

Moving Business Logic Into The Domain

Moving Validation Rules Into The Domain

Expressing Side Effects With Domain Events

Takeaway

Key phrases

Older messages

MNW #041: The Right Way To Use HttpClient In .NET

MNW #040: Scheduling Background Jobs With Quartz.NET

MNW #039: Build a CI/CD Pipeline With GitHub Actions And .NET

MNW #038: Multi-Tenant Applications With EF Core

MNW #037: Visualize Your Software Architecture With The C4 Model

You Might Also Like

🕹️ How to Play Retro Games for Free on iPhone — Why I Can't Live Without an eReader

Weekend Reading — The Bob Ross of programming

Issue #538: All the Jam entries, Panthera 2, and Tristram

Daily Coding Problem: Problem #1424 [Easy]

Charted | Countries That Became More Happy (or Unhappy) Since 2010 😅

Noonification: What Is E-Waste Hacking?

TikTok faces a ban in the US, Tesla profits drop and healthcare data leaks

🐍 New Python tutorials on Real Python

Bogus npm Packages Used to Trick Software Developers into Installing Malware

This Smart Scale for iPhone Is the Best on the Market