Anemic Domain Model: Pros/Cons

F

17

87

I would like to know what the pros and cons are for using an Anemic Domain Model (see link below).

Fowler Article

Frondescence answered 3/11, 2008 at 12:49 Comment(0)

C

37

The pros:

You can claim it's a domain model and brag to your developer friends and put it on your resume.
It's easy to generate automagically from database tables.
It maps to Data Transfer Objects surprisingly well.

The cons:

Your domain logic exists somewhere else, probably in a class full of class(static) methods. Or your GUI code. Or in multiple places, all with conflicting logic.
It's an anti-pattern, so other developers will ask if you understand the concepts of object oriented design.

Cass answered 7/11, 2008 at 19:15 Comment(16)

+1 The point about generating the code from database tables is very important for some people. If you're in a rapid-prototyping mode of development, automatic code generation is extremely helpful. We don't pretend this is proper OO design, and putting things together in a sloppy way produces "technical debt." Nevertheless, in many projects time-to-market is a higher priority. – Srini 5/11, 2009 at 16:22

No. Whether an anemic model is an anti-pattern is a matter of opinion. Fowler (whose work I respect and typically follow) says it is. I disagree (not that my word has any weight), and many in the OO trenches disagree as well. Pure OO modeling is not generally applicable in every case, that the whole industry knows from experience. Furthermore, an anemic model can still abide by OO modeling guidelines. So seeing specific cases where one applies does not bring into question one's understanding of OO design. – Ta 31/3, 2011 at 14:37

Whether any pattern is an anti-pattern is a matter of opinion. A robust domain model is good OO design and an anemic domain model is bad OO design. Therefore, in the context of OO, it's an anti-pattern. That doesn't mean it doesn't get used or is inappropriate in all cases, but from personal experience I consider it worse than singleton addiction. – Cass 31/3, 2011 at 16:15

I feel there is a trend towards functional programming, and domain model tend to have a lot of side effects. I'm getting a feeling anemic domain model is making a comeback because it allows for a more functional style of programming, where your business logic expects data in and returns processed data out. Your service layer supervises the flow of it all, by knowing which data is required to be processed by which business logic method. – Egis 20/2, 2014 at 20:28

The Domain Model pattern (and Anemic version) both deal with objects. It doesn't make much sense to use object oriented design patterns in functional programming, does it? – Cass 20/2, 2014 at 20:51

@TerryWilcox Well, I'm no functional expert, but functional programming have data structures too. An anemic domain model uses object just as containers of data, they are more like structs. My point is that with ADM, you can kind of move toward a more functional way, where you have immutable data that is transformed over time into newer and newer states. I can see this being done in Scala for example, trying to leverage a bit of OOP and apply some FP to it. A bit like they explain it here: slideshare.net/debasishg/qconny-12 – Egis 21/2, 2014 at 19:6

If you want structs, use structs. If you must use objects for it, dump accessor methods and just leave public variables. Accessor methods can have side effects. – Cass 21/2, 2014 at 21:36

@TerryWilcox I don't see any argument in your answer as to why one is better than the other. You simply stated an opinion. -1 – Merari 3/3, 2014 at 10:52

@Merari Yes, this is all opinion. Functional programming likes to avoid side effects. OO uses side effects, sometimes in accessor methods. In my opinion, having accessor methods makes side effects more possible than using naked public variables. – Cass 3/3, 2014 at 14:56

@TerryWilcox If only a constructor and getters are available you'd be wrong. If getters and setters are available it would depend upon the developers tendencies. I'm sure you know the advantages of getters and setters. If they're verbose, it's a problem with your language. – Merari 3/3, 2014 at 17:53

I'm curious to know whether you still stick to this answer, seven years later. These days, the ADM is widely recognised as being the better option as it better complies with SOLID principles, is easier to unit test and easier to maintain and refactor. The RDM is arguably the anti-pattern and ADM the better use of OO. – Endogenous 12/1, 2016 at 13:56

@DavidArno Do you have any references to where that is widely recognized in the OO context? – Cass 12/1, 2016 at 15:0

@TerryWilcox, references, no. What I've been doing is going through SO/Programmers questions related to the Anaemic Data Model and comparing the dates of the answers against up/down votes. There seems to be two trends. Older questions have answers saying it's an anti-pattern, lots of up-votes for those answers, but also lots of down votes for the same answers (such as your one here). Questions in the last couple of years though tend to have answers saying the ADM is a good thing, which have been highly up-voted and suffer little down-votes. – Endogenous 12/1, 2016 at 15:21

@TerryWilcox, whilst this is far from a rigorous analysis of prevaling opinion, it certainly suggests that those still supporting Fowler's opinion from over a decade ago are becoming the minority and the majority view is shifting to the ADM being the better choice (no doubt significantly driven by both the shift to TDD and to more functional-orientated approaches to programming). – Endogenous 12/1, 2016 at 15:23

@DavidArno I would guess the majority of down votes come from programmers who use functional languages, but mistakenly cling to OO concepts. The Domain Model pattern, anemic or otherwise, is an OO pattern. It makes no sense to speak of it in a non-OO context, like functional programming. – Cass 12/1, 2016 at 15:53

@DavidArno So to answer your original question; in hindsight I wouldn't have answered this question at all. – Cass 12/1, 2016 at 16:1

F

140

With "Anemic Domain Model" being anti-pattern, why are there so many systems that implement this?

I think there are several reasons

1. Complexity of the system

In a simple system (which is almost all the examples and sample code you find on internet) if I want to implement:

Adding product to Order

I put this function on the Order

public void Order.AddOrderLine(Product product)
{
    OrderLines.Add(new OrderLine(product));
}

Nice and super object oriented.

Now let's say that I need to make sure that I need to validate that the product exists in inventory and throw exception if it doesn't.

I can't really put it on Order any longer, since I don't want my order to be dependent on Inventory, so now it needs to go on the service

public void OrderService.AddOrderLine(Order order, Product product)
{
    if (!InventoryService.Has(product)
       throw new AddProductException

    order.AddOrderLine(product);
}

I could also pass IInventoryService to Order.AddOrderLine, which is another option, but that still makes Order dependent on InventoryService.

There is still some functionality in Order.AddOrderLine, but usually it is limited to Order scope, while in my experience there is a lot more Business Logic out of Order scope.

When the system is more then just basic CRUD, you will end up with most of your logic in OrderService and very little in Order.

2. Developer's view of OOP

There are a lot of heated discussions on the internet about which logic should go on entities.

Something like

Order.Save

Should Order know how to save itself or not? Let's say we have repositories for that.

Now can Order add order lines? If I try to make sense of it using simple English, it doesn't really make sense either. User adds Product to Order, so should we do User.AddOrderLineToOrder()? That seems like overkill.

How about OrderService.AddOrderLine(). Now it kinda makes sense!

My understanding of OOP is that for encapsulation you put functions on classes where the function will need to access class's internal state. If I need to access Order.OrderLines collection, I put Order.AddOrderLine() on Order. This way class's internal state doesn't get exposed.

3. IoC Containers

Systems that use IoC containers are usually fully anemic.

It is because you can test your services/repositories which have interfaces, but can't test domain objects (easily), unless you put interfaces on all of them.

Since "IoC" is currently lauded as solution for all your programming problems, a lot of people blindly follow it and this way end up with Anemic Domain Models.

4. OOP is hard, procedural is easy

I have a bit of a "Curse of Knowledge" on this one, but I have discovered that for newer developers having DTOs and Services is a lot easier than Rich Domain.

Possibly it is because with Rich Domain it is more difficult to know on which classes to put the logic. When to create new classes? Which patterns to use? etc..

With stateless services you just slap it in the service with closest name.

Faught answered 1/5, 2011 at 8:10 Comment(7)

I think it would depend on how complex it would get. 1. If it simple as in 1-2 dependencies - I would keep it on Order class. 2. If moderate complexity - I would create OrderLines class and use Order.OrderLines to handle Order <-> OrderLines communication as well as related dependencies. 3. But in case of high complexity - I would use Application service OrderService to allow for most external dependencies, while keeping any Order module scoped logic in Order. – Faught 4/1, 2013 at 11:49

Great summary - all of these reasons are why its not an anti-pattern. Slavish devotion to OO is an antipattern. Now add in concurrency without projection and watch how you tie yourself in knots with Fowler style OO. Look at companies doing concurrency at scale (e.g. google) and see how much OO they are doing. – Reinareinald 15/3, 2013 at 10:24

Nicely said. Using Grails, I'm not sure 3° leads to anemia. As for 1°, indeed, you end moving logic in the service layer in any non trivial application. But I still find myself with a domain-centric approach using Grails. Which makes it actually not so good, since your domain is your preferred place for logic but you move bits up one layer when needed. – Heymann 28/6, 2013 at 19:52

I don't see the IoC-to-Anemic correlation. It seems like a completely unrelated issue. Whether your services/repositories OR domain objects implement interfaces has nothing to do with testing them. Rather, you test services/repositories/domain objects and decouple them from their dependencies which themselves implement interfaces. And whether you do this right or not doesn't have any correlation to IoC that I can see. – Bonne 29/7, 2013 at 19:15

The thing about DDD that I'm struggling to Grok is your first point: "When the system is more then just basic CRUD, u will end up with most of your logic in OrderService and very little in Order." That makes sense to me, but isn't the purpose of DDD to be used for systems that are more complex than that? – Jamima 5/5, 2014 at 17:51

Great discussion, but I also don't see IoC containers causing anemic model at all. There is an interesting point: In order for a model to have rich behaviors it will often need to collaborate with dependencies (the validation service for example). A problem that is often unsolved: How to give dependencies to model objects, simply hard-wiring them can lead to the problems outlined that occur from not doing DI, so another approach is required. But other approaches have complexities of their own. – Patinous 22/10, 2014 at 12:2

Although I don't disagree with your points (which boil down to 'OOP is hard' maybe?) 1 is based on a straw man argument - an OOP solution would be to ask product.in_stock? NOT to draw in a service. Once could also invoke "tell don't ask" and, well, a lot of other design techniques. Basically your example is good as to WHY OOP is hard, but isn't a good example of why services can/should be used. – Mechling 23/4, 2017 at 21:32

C

37

The pros:

You can claim it's a domain model and brag to your developer friends and put it on your resume.
It's easy to generate automagically from database tables.
It maps to Data Transfer Objects surprisingly well.

The cons:

Your domain logic exists somewhere else, probably in a class full of class(static) methods. Or your GUI code. Or in multiple places, all with conflicting logic.
It's an anti-pattern, so other developers will ask if you understand the concepts of object oriented design.