3

I am trying to get a firm understanding of DDD and having read Eric Evans book on Domain Driven Design and blogs from Julie Lerman they describe:

Anemic Domain Model as a model with classes focused on state management. Good for CRUD.

Entity as a mutable class with an identity used for tracking and persistence.

Surely both are used for the same purpose or I have completely got the wrong end of the stick? What is the difference between the two? I have read that an anemic domain model is often used to represent a database schema, but isn't the same for an entity too?

For example, a table called Customer which has:

CustomerId int
Forename varchar(50)
Surname varchar(50)
IsActive bit

From my understanding an anemic domain model to represent this would look like:

public class Customer
{
  public int CustomerId { get; set; }
  public string Forename { get; set; }
  public string Surname { get; set; }
}

Past experiences for me suggest that an entity would also be represented in this fashion with a series of getter and setter properties, a la Entity Framework? Both concepts (entity and an anemic domain model) are mutable?

Thanks, DS.

Dr Schizo
  • 4,045
  • 7
  • 38
  • 77
  • 1
    I would say **they are from two different worlds.** It is better to compare **anemic vs rich domain model** or **data transfer object vs entity/value object/aggregate root**. – Ilya Palkin Sep 09 '14 at 20:17
  • Again the issue here is how can we treat a DTO / entity and a value object the same as a value object is immutable whereas an entity and a DTO isn't. For it to change state is acceptable. – Dr Schizo Sep 09 '14 at 20:43
  • Anemic domain model and DTOs have no behaviour. Rich domain model and entities/value objects/aggregate roots have it. You are right that entity, value object and aggregate root are different, but all of them usually have behavior. – Ilya Palkin Sep 09 '14 at 21:37
  • If you use EF entities in your domain you'll never get the domain entities you want, it's virtually impossible. For example the first modification I'd make to your `Customer` class would be to make the `CustomerId` readonly, or even completely private. – Adrian Thompson Phillips Sep 10 '14 at 10:46

2 Answers2

2

A DDD Customer entity might have Customer::changeName(Forename,Surname)...;

changeName would only be triggered if the customer is actually changing their name. You would then embed whatever business logic is necessary for dealing with a new name. Perhaps there are pending orders with the old name. Maybe you want to update them to the new name. Maybe not. Lot's of possibilities.

For me at least the basic difference between a anemic domain object and a DDD entity is that the entity is going to actually do something more than just update properties.

Cerad
  • 48,157
  • 8
  • 90
  • 92
  • What you're describing there is a rich domain model. Are you saying an entity is equivalent to this? Eric Evans distinguishes the two which is where the confusion arises. – Dr Schizo Sep 09 '14 at 18:03
  • To be perfectly honest I don't spend much time trying to parse subtle differences between authors. None of the usual DDD experts have come by and down voted me yet which is encouraging. Have to see what happens. – Cerad Sep 09 '14 at 19:00
  • +1, methods in Entities should reflect events that happen in real life and are expressed in the application's Ubiquitous Language. Customers don't "set their street to X and city to Y", they "change their delivery info". @Dr Schizo How does Eric Evans distinguish rich domain model from Entity ? To me, an Entity is just a subpart of a rich domain model -- RDM is just a way of referring to the Domain layer classes as a whole (Entities, Value Objects, Services). – guillaume31 Sep 10 '14 at 10:03
  • I would consider handling pending orders as part of the orders domain not customer. I would recommend using the observer pattern here, so orders can subscribe to be notified of changes to the related customer. – Adam Burley Oct 27 '22 at 10:48
1

[ I have read that an anemic domain model is often used to represent a database schema, ] but isn't the same for an entity too?

Maybe you should re-read Evans' book ;) A DDD entity is one way of implementing the Rich Domain Model approach. An Entity is rich in that it captures domain actions that are referenced in the Ubiquitous Language of the application. These actions encode real-life events that can happen in a business domain, as opposed to atomic, disembodied modifications of data slots. For example, you could have an Order.ApplyDiscountVoucher(...) method that checks voucher validity and recalculates order total, as opposed to just exposing an Order.Total property and leaving it up to an external script to check the voucher and update the total.

Also encapsulated in an Entity is the responsibility of enforcing invariants, which can be applied at Entity creation or, for Entities that are Aggregate Roots, each time someone tries to change the Aggregate. An anemic model wouldn't have these business rules built in, they would be tackled in external procedures.

Whether entities, other domain objects or anemic objects should be mutable is a completely orthogonal issue to this.

guillaume31
  • 13,738
  • 1
  • 32
  • 51
  • That section you highlighted above came from a PluralSight video Domain Driven Design Fundamentals by Julie Lerner :) – Dr Schizo Sep 10 '14 at 11:20
  • 1
    Do you mean, she asked this very question, or she stated that "it's the same for an entity" ? Maybe she was talking about Entity Framework's Entities which are very different from DDD's Entities. – guillaume31 Sep 10 '14 at 13:07
  • Well they (Lerner and Smith) mentioned sometimes anemic domain model is often used as to represent database schema. I know she is an advocate for EF hence where this could have come from, hence my confusion. I think the diagram they use which shows the bounded context and where the entity portion lives in that explains a lot of things. – Dr Schizo Sep 10 '14 at 14:11
  • Well my answer was to your *"but isn't the same for an entity too?"* part and not her *"an anemic domain model is often used to represent a database schema"* part which is, I believe, valid ;) – guillaume31 Sep 10 '14 at 14:34