Is an ANEMIC Domain Model really that BAD?

Is an anemic domain model a bad thing? Most would probably call it an anti-pattern, and it should be avoided. But is that really true? Well, it depends on what your intent is. Are you trying to create a domain model? Or are you really just trying to create a data model?


Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything in this post.


In this post, I’m going to be using the example of a food delivery service. You order food from the restaurant and it’s delivered to you.

There is the concept of a shipment which is the delivery of your food order. Every shipment has two stops. The first stop is the Pickup which is the restaurant, and the second stop is the Delivery which is your house/apartment/work or wherever you’re getting the food delivered to.

Conceptual Model

Each stop (Pickup and Delivery) goes through a progression from being In-Transit, Arrived, and Departed.

Stop Progression

The first Stop must go through this full progression before the second Stop can start. This makes sense because the food delivery driver must first Arrive at the Restaurant (the first stop). Once they pick up the food, they depart. Once they have departed the First Stop, then they can Arrive at your house/apartment/work for the delivery. Once they deliver the food, the second stop is now Departed.

Anemic Domain Model

An anemic domain model is an object model that contains a data structure but no behavior. In the case of my shipment example, this means it has an object for the Shipment and the Stops, but no behavior within the objects to make the stop progressions.

While there are a few methods for setting data, this isn’t behavior. We need logic to control the Status on a stop. For example, we can’t change the Stop Status on the Delivery Stop to Arrived if we haven’t Departed the Pickup Stop.

There is no behavior, my object model of Shipment and Stops are just data buckets.

So where does the logic live? In an anemic domain model, generally, you’ll find these in a “Service” or “Manager”. So in this example, you’d likely have a ShipmentService or ShipmentManager that contains the logic.

In the ShipmentService above, we do have logic in various methods for validating that the current state is valid before we perform a state change. Also, note that most of these methods are taking the shipment as a parameter however sometimes I see data access done directly within these methods.

Regardless of where the data access is, the point is that the logic resides separately from the data. The object method of Shipment and Stops are just data buckets and contain no actual logic. All of the logic is separated and contained within inside the ShipmentService which then mutates the Shipment and Stops.

So what’s the issue with this?

It depends on what your intent is. If you’re intent is to make an object-oriented domain model, then this isn’t it. You’ve made an object method that represents the data structure. You’ve made a data model. You think you have a domain model, but you really just have a data model.

Now I suspect most people aren’t trying to create a domain model, what they’re really doing is just trying to create some separation or layering (more on this later in this post). What you’re really closer to are Transaction Scripts.

Entity Services depend on an ORM for data access. The ORM provides returns Entities that are really a one-to-one mapping of a table structure if you’re using a relational database.

Anemic Domain Model


Now I actually view most anemic domain models closer to Transaction Scripts than I do a Domain Model. Anemic domain models are kind of this in-between phase of going a bit further than a Transaction Script but not all the way to a Domain Model.

Transaction Script to Anemic Domain Model, to Domain Model

Transaction scripts are much more procedural and often times has many more mixed concerns, such as data access, validation, etc.

The intent of a transaction script is to handle a single request. It contains everything. It would contain the data access to get out the Entities/Domain Objects. It would contain all the validation logic and also state changes.

Transaction Script

Because you have many mixed concerns, people want to separate these concerns and land with Anemic Domain Models.

Where this starts falling apart is when you need to duplicate logic or state changes that exist in multiple different transaction scripts. When you start seeing this duplication, you then want to start having transaction scripts call other transaction scripts so you can reuse them and stop duplicating code.

Transaction Script calling another Transaction Script

This becomes difficult because if they both contain their own data access logic, then there’s often no simple way of sharing the same underlying transaction.

Once people hit this point, this is where I believe they start going down the Anemic Domain Model path. Instead of duplicating code in different transaction scripts, that’s shared within a single class that turns into the Service (eg, ShipmentService).

Domain Model

The alternative is to have a domain model that exposes behaviors and encapsulates data. Don’t separate the behaviors from the data like you are with an anemic domain model. Keep both behaviors and data within the same object model.

Domain Model

Similar to a transaction script, it can be the one delegating what to do. It can provide the data access to retrieve and/or build our domain model (often an Aggregate Root). It can then call the relevant public methods on the domain model to perform the requested command/action.

The constructor takes a list of Stops. The only way a Stop can be mutated is by calling methods on the ShipmentAggregateRoot. We’re hiding (encapsulating) the data and only exposing behaviors.

To invoke our domain model, we have command handlers that get our Aggregate Root via a Repository, call the appropriate method, then save the aggregate.

Similar to a transaction script, it’s handling a single request, but now instead of having mixed concerns within it, it’s simply delegating to data access and our aggregate root.

Anemic Domain Model

Is an anemic domain model a terrible thing and an anti-pattern that you should avoid? Well, it depends on what your intent is! If you’re trying to create a domain model because you have a lot of complexity, then yes it’s an anti-pattern. However, if you don’t have a lot of complexity that warrants a domain model, a transaction script might be better served for simplicity.

If you’re using transaction scripts and things start getting more and more complex or you start duplicating logic across transaction scripts, then start thinking about building a domain model that hides (encapsulates) data and exposes behaviors.


Developer-level members of my YouTube channel or Patreon get access to a private Discord server to chat with other developers about Software Architecture and Design as well as access to source code for any working demo application that I post on my blog or YouTube. Check out the YouTube Membership or Patreon for more info.

Follow @CodeOpinion on Twitter

Software Architecture & Design

Get all my latest YouTube Vidoes and Blog Posts on Software Architecture & Design

CRUD API + Complexity = Death by a 1000 Papercuts

Focusing on CRUD API (Create, Read Update, Delete) and Entities force your end-users to perform the business logic and workflow themselves. Meaning they must know the logic since it’s in their head and not in your system. While CRUD sounds simple, I’ll illustrate how adding business logic to a CRUD-driven system can lead to a lot of complexity and how focusing on tasks instead can lead to a more explicit design that captures intent.


Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything that is in this post.


The predominant way that most people learn any type of web framework or how to write a basic web application is to pass around entities or data objects that represent a record in a database.

The Client makes a request to your application or service, and then it in turns queries your database to get data out of it. This could be using an ORM with a relational database or perhaps a document database.

The app service at this point may transform the data, depending on its shape, to an entity or some other type of data model. But usually, it represents a 1-to-1 mapping of an “entity” or database record. This is what will be returned to the client.

The client code will generally take this entity and provide the user with a UI form to update any relevant properties of the entity.

Once the user submits the form, that entity will be sent back to the Application/Service where it will update the record in the database.

This is pretty much the basics of any type of CRUD API. It focuses on “entities” or data models and Create, Read, Update, Delete operations around them.

For the most part, the application/service becomes a proxy to your database. Yes, it may have some superficial validation on the data or be handling your authentication, but really it’s just transforming data out and back into the database.

CRUD Gone Crazy

Below is a screenshot of a post on Reddit a few years ago that was asking if they should create a microservice per table.

CRUD API + Complexity = Death by a 1000 Papercuts

In case you were wondering the answer to the question, my answer is no, absolutely not.

This does illustrate however the general focus on Entities and a CRUD API, and how so many blog posts, tutorials, videos are giving examples of this exact basic pattern around CRUD and Entities.

CRUD isn’t bad. It has its place. If you’re developing a small simple app, sure, by all means, use CRUD. However, if you’re developing a larger system with many different boundaries, you’re likely to have complexity in your domain that can’t simply be managed by typical CRUD apps.

Here’s an example of a product in a warehouse that is based on CRUD API. In this example, I’m specifically illustrating reading and updating a Product via an HTML form.

CRUD API + Complexity = Death by a 1000 Papercuts

There is an ASP.NET Core Controller that handles returning the HTML View and then a route for handling the form POST for updating the product. A very basic Service-side rendering type of form.


The above has no complexity. However, let’s say we have a new requirement that we can only mark an item for sale if we have any amount of quantity on hand.

Well, we can implement that by doing that check in our controller when we set the ForSale property. No problem.

Let’s add some more logic to that to also specify that the price must be greater than zero in order for the product to be for sale. Again, no problem.

Here are the changes to the UpdateProduct.

While this example is trivial, this starts turning into a slow death by 1000 papercuts. As any system evolves, more and more complexity is added slowly over time. Unmanaged you can end up with so much complexity it makes it very difficult to change anything even with good test coverage because the setup for these becomes so complex.

Another issue is that all this logic resides in a controller that isn’t easily invoked by another application code. You cannot bypass this code.

However, a not so commonly talked about issue with the above is that this logic does not inform the user about the rules we’ve defined. It’s good that we now have this logic in our application, however, we’re not providing the end-user with any information about why the ForSale property isn’t being set.

If the end-user in the UI set the For Sale toggle to ON, but the quantity was set to 0, once they clicked save and were redirected back to the form, the For Sale toggle would be set back to OFF. They would likely think something is broken since it didn’t actually save what they intended.

Now you can overcome this by providing the end-users with validation warnings or errors. You can take CRUD pretty far, however in my experience when you’re in a domain with complexity this becomes death by 1000 papercuts and becomes unmanageable using CRUD.

Task Driven

The alternative to CRUD is being Task Driven. Provide your end-users with specific Tasks that represent explicit actions they take. With CRUD, the end-user has a specific goal in mind when they were editing the form. CRUD is very implicit.

If they were changing the quantity on hand, there was a specific business case they were doing that for. It could be because they did a stock count and have to do an Inventory Adjustment. An inventory adjustment is a specific capability you provide. Providing the ability to do an Inventory Adjustment is much more explicit.

CRUD API + Complexity = Death by a 1000 Papercuts

Some portions of the UI can simply still be CRUD-driven. For example, the name and description are separate form for updating them. There is no business logic around those. The Price has various business reasons why it would be changed. Is it a price increase or a price decrease?

This may sound trivial but again making this explicit means you have explicit code that handles each task. You may want to publish an event of ProductPriceDecreased when a price decreases to email existing customers about the price change.

In code, this is reflected by organizing code by actual task.

Files are defined by Commands (State Change) or Queries (Return State). The AvailableForSale command looks like this:

You can also see that we’re not doing the state changes or logic to the product within the controller, rather doing it in the Product Entity itself.


CRUD API isn’t bad but it is a nightmare when you actually need to handle complexity. If you want to develop a system that moves logic out of end-users heads and lets them perform their job with the business capabilities they expect, then be task-driven and focus on business capabilities.

Source Code

Developer-level members of my YouTube channel or Patreon get access to the full source for any working demo application that I post on my blog or YouTube. Check out the YouTube Membership or Patreon for more info.

Follow @CodeOpinion on Twitter

Software Architecture & Design

Get all my latest YouTube Vidoes and Blog Posts on Software Architecture & Design