Rich vs Anemic Domain Model

I am deciding if I should use a Rich Domain Model over an Anemic Domain Model, and looking for good examples of the two.

I have been building web applications using an Anemic Domain Model, backed by a Service --> Repository --> Storage layer system, using FluentValidation for BL validation, and putting all of my BL in the Service layer.

I have read Eric Evan's DDD book, and he (along with Fowler and others) seems to think Anemic Domain Models are an anti-pattern.

So I was just really wanting to get some insight into this problem.

Also, I am really looking for some good (basic) examples of a Rich Domain Model, and the benefits over the Anemic Domain Model it provides.

The difference is that an anemic model separates logic from data. The logic is often placed in classes named **Service, **Util, **Manager, **Helper and so on. These classes implement the data interpretation logic and therefore take the data model as an argument. E.g.

public BigDecimal calculateTotal(Order order){
...
}

while the rich domain approach inverses this by placing the data interpretation logic into the rich domain model. Thus it puts logic and data together and a rich domain model would look like this:

order.getTotal();

This has a big impact on object consistency. Since the data interpretation logic wraps the data (data can only be accessed through object methods) the methods can react to state changes of other data -> This is what we call behavior.

In an anemic model the data models can not guarantee that they are in a legal state while in a rich domain model they can. A rich domain model applies OO principles like encapsulation, information hiding and bringing data and logic together and therefore a anemic model is an anti pattern from an OO perspective.

For a deeper insight take a look at my blog https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/

Bozhidar Bozhanov seems to argue in favor of the anemic model in this blog post.

Here is the summary he presents:

• domain objects should not be spring (IoC) managed, they should not have DAOs or anything related to infrastructure injected in them

• domain objects have the domain objects they depend on set by hibernate (or the persistence mechanism)

• domain objects perform the business logic, as the core idea of DDD is, but this does not include database queries or CRUD – only operations on the internal state of the object

• there is rarely need of DTOs – the domain objects are the DTOs themselves in most cases (which saves some boilerplate code)

• services perform CRUD operations, send emails, coordinate the domain objects, generate reports based on multiple domain objects, execute queries, etc.

• the service (application) layer isn’t that thin, but doesn’t include business rules that are intrinsic to the domain objects

• code generation should be avoided. Abstraction, design patterns and DI should be used to overcome the need of code generation, and ultimately – to get rid of code duplication.

UPDATE

I recently read this article where the author advocates of following a sort of hybrid approach - domain objects can answer various questions based solely on their state (which in the case of totally anemic models would probably be done in the service layer)

My point of view is this:

Anemic domain model = database tables mapped to objects (only field values, no real behavior)

Rich domain model = a collection of objects that expose behavior

If you want to create a simple CRUD application, maybe an anemic model with a classic MVC framework is enough. But if you want to implement some kind of logic, anemic model means that you will not do object oriented programming.

*Note that object behavior has nothing to do with persistence. A different layer (Data Mappers, Repositories e.t.c.) is responsible for persisting domain objects.

When I used to write monolithic desktop apps I built rich domain models, used to enjoy building them.

Now I write tiny HTTP microservices, there's as little code as possible, including anemic DTOs.

I think DDD and this anemic argument date from the monolithic desktop or server app era. I remember that era and I would agree that anemic models are odd. I built a big monolithic FX trading app and there was no model, really, it was horrible.

With microservices, the small services with their rich behaviour, are arguably the composable models and aggregates within a domain. So the microservice implementations themselves may not require further DDD. The microservice application may be the domain.

An orders microservice may have very few functions, expressed as RESTful resources or via SOAP or whatever. The orders microservice code may be extremely simple.

A larger more monolithic single (micro)service, especially one that keeps it model in RAM, may benefit from DDD.

> First of all, I copy pasted the answer from this article > http://msdn.microsoft.com/en-gb/magazine/dn385704.aspx

Figure 1 shows an Anemic Domain Model, which is basically a schema with getters and setters.

Figure 1 Typical Anemic Domain Model Classes Look Like Database Tables

public class Customer : Person
{
  public Customer()
  {
    Orders = new List<Order>();
  }
  public ICollection<Order> Orders { get; set; }
  public string SalesPersonId { get; set; }
  public ShippingAddress ShippingAddress { get; set; }
}
public abstract class Person
{
  public int Id { get; set; }
  public string Title { get; set; }
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public string CompanyName { get; set; }
  public string EmailAddress { get; set; }
  public string Phone { get; set; }
}

In this richer model, rather than simply exposing properties to be read and written to, the public surface of Customer is made up of explicit methods.

Figure 2 A Customer Type That’s a Rich Domain Model, Not Simply Properties

public class Customer : Contact
{
  public Customer(string firstName, string lastName, string email)
  {
    FullName = new FullName(firstName, lastName);
    EmailAddress = email;
    Status = CustomerStatus.Silver;
  }
  internal Customer()
  {
  }
  public void UseBillingAddressForShippingAddress()
  {
    ShippingAddress = new Address(
      BillingAddress.Street1, BillingAddress.Street2,
      BillingAddress.City, BillingAddress.Region,
      BillingAddress.Country, BillingAddress.PostalCode);
  }
  public void CreateNewShippingAddress(string street1, string street2,
   string city, string region, string country, string postalCode)
  {
    ShippingAddress = new Address(
      street1,street2,
      city,region,
      country,postalCode)
  }
  public void CreateBillingInformation(string street1,string street2,
   string city,string region,string country, string postalCode,
   string creditcardNumber, string bankName)
  {
    BillingAddress = new Address      (street1,street2, city,region,country,postalCode );
    CreditCard = new CustomerCreditCard (bankName, creditcardNumber );
  }
  public void SetCustomerContactDetails
   (string email, string phone, string companyName)
  {
    EmailAddress = email;
    Phone = phone;
    CompanyName = companyName;
  }
  public string SalesPersonId { get; private set; }
  public CustomerStatus Status { get; private set; }
  public Address ShippingAddress { get; private set; }
  public Address BillingAddress { get; private set; }
  public CustomerCreditCard CreditCard { get; private set; }
}

One of the benefit of rich domain classes is you can call their behaviour (methods) everytime you have the reference to the object in any layer. Also, you tend to write small and distributed methods that collaborate together. In anemic domain classes, you tend to write fat procedural methods (in service layer) that are usually driven by use case. They are usually less maintainable compared to rich domain classes.

An example of domain classes with behaviours:

class Order {

     String number

     List<OrderItem> items

     ItemList bonus

     Delivery delivery

     void addItem(Item item) { // add bonus if necessary }

     ItemList needToDeliver() { // items + bonus }

     void deliver() {
         delivery = new Delivery()
         delivery.items = needToDeliver()
     }

}

Method needToDeliver() will return list of items that need to be delivered including bonus. It can be called inside the class, from another related class, or from another layer. For example, if you pass Order to view, then you can use needToDeliver() of selected Order to display list of items to be confirmed by user before they click on save button to persist the Order.

Responding To Comment

This is how I use the domain class from controller:

def save = {
   Order order = new Order()
   order.addItem(new Item())
   order.addItem(new Item())
   repository.create(order)
}

The creation of Order and its LineItem is in one transaction. If one of the LineItem can't be created, no Order will be created.

I tend to have method that represent a single transaction, such as:

def deliver = {
   Order order = repository.findOrderByNumber('ORDER-1')
   order.deliver()       
   // save order if necessary
}

Anything inside deliver() will be executed as one single transaction. If I need to execute many unrelated methods in a single transaction, I would create a service class.

To avoid lazy loading exception, I use JPA 2.1 named entity graph. For example, in controller for delivery screen, I can create method to load delivery attribute and ignore bonus, such as repository.findOrderByNumberFetchDelivery(). In bonus screen, I call another method that load bonus attribute and ignore delivery, such as repository.findOrderByNumberFetchBonus(). This requires dicipline since I still can't call deliver() inside bonus screen.

I think the root of the problem is in false dichotomy. How is it possible to extract these 2 models: rich and "anemic" and to contrast them to each other? I think it's possible only if you have a wrong ideas about what is a class. I am not sure, but I think I found it in one of Bozhidar Bozhanov videos in Youtube. A class is not a data + methods over this data. It's totally invalid understanding which leads to the division of classes into two categories: data only, so anemic model and data + methods - so rich model (to be more correct there is a 3rd category: methods only even).

The true is that class is a concept in some ontological model, a word, a definition, a term, an idea, it's a DENOTAT. And this understanding eliminates false dichotomy: you can not have ONLY anemic model or ONLY rich model, because it means that your model is not adequate, it's not relevant to the reality: some concepts have data only, some of them have methods only, some of them are mixed. Because we try to describe, in this case, some categories, objects sets, relations, concepts with classes, and as we know, some concepts are processes only (methods), some of them are set of attributes only (data), some of them are relations with attributes (mixed).

I think an adequate application should include all kinds of classes and to avoid to fanatically self-limited to just one model. No matter, how the logic is representing: with code or with interpretable data objects (like Free Monads), anyway: we should have classes (concepts, denotats) representing processes, logic, relations, attributes, features, data, etc. and not to try to avoid some of them or to reduce all of them to the one kind only.

So, we can extract logic to another class and to leave data in the original one, but it has not sense because some concept can include attributes and relations/processes/methods and a separating of them will duplicate the concept under 2 names which can be reduced to patterns: "OBJECT-Attributes" and "OBJECT-Logic". It's fine in procedural and functional languages because of their limitation but it's excessive self-restraint for a language that allows you to describe all kinds of concepts.

Anemic domain models are important for ORM and easy transfer over networks (the life-blood of all comercial applications) but OO is very important for encapsulation and simplifying the 'transactional/handling' parts of your code.

Therefore what is important is being able to identify and convert from one world to the other.

Name Anemic models something like AnemicUser, or UserDAO etc so developers know there is a better class to use, then have an appropriate constructor for the none Anemic class

User(AnemicUser au)

and adapter method to create the anemic class for transporting/persistence

User::ToAnemicUser() 

Aim to use the none Anemic User everywhere outside of transport/persistence

The classical approach to DDD doesn't state to avoid Anemic vs Rich Models at all costs. However, MDA can still apply all DDD concepts (bounded contexts, context maps, value objects, etc.) but use Anemic vs Rich models in all cases. There are many cases where using Domain Services to orchestrate complex Domain Use Cases across a set of domain aggregates as being a much better approach than just aggregates being invoked from application layer. The only difference from the classical DDD approach is where does all validations and business rules reside? There’s a new construct know as model validators. Validators ensure the integrity of the full input model prior to any use case or domain workflow takes place. The aggregate root and children entities are anemic but each can have their own model validators invoked as necessary, by it’s root validator. Validators still adhered to SRP, are easy to maintain and are unit testable.

The reason for this shift is we’re now moving more towards an API first vs an UX first approach to Microservices. REST has played a very important part in this. The traditional API approach (because of SOAP) was initially fixated on a command based API vs. HTTP verbs (POST, PUT, PATCH, GET and DELETE). A command based API fits well with the Rich Model object oriented approach and is still very much valid. However, simple CRUD based APIs, although they can fit within a Rich Model, is much better suited with simple anemic models, validators and Domain Services to orchestrate the rest.

I love DDD in all that it has to offer but there comes a time you need stretch it a bit to fit constantly changing and better approach to architecture.

Here is a example that might help:

Anemic

class Box
{
    public int Height { get; set; }
    public int Width { get; set; }
}

Non-anemic

class Box
{
    public int Height { get; private set; }
    public int Width { get; private set; }

    public Box(int height, int width)
    {
        if (height <= 0) {
            throw new ArgumentOutOfRangeException(nameof(height));
        }
        if (width <= 0) {
            throw new ArgumentOutOfRangeException(nameof(width));
        }
        Height = height;
        Width = width;
    }

    public int area()
    {
       return Height * Width;
    }
}