The Rotten Domain Model is dead; long live the Abstracted Domain Model

! Warning: this post hasn't been updated in over three years and so may contain out of date information.

abstractMany years ago, back when OO was a new, exciting idea that appeared to offer a panacea solution to developing applications, Martin Fowler wrote an article entitled “Anemic Domain Model” (ADM), in which he argued that separating data from functionality, within the OO paradigm, is an anti pattern.

Twelve years later, things have moved on quite a bit. Many now recognise the benefits of such a split; yet some still, near-religiously, stick to the idea that the anaemic data model is somehow “not real OO”. Part of this stems from the (presumably deliberate) use of a negative term to describe that separation approach. It’s therefore time to fight back with new definition of the terms “RDM” and “ADM”, to help move us away from the antiquated view that separating data from functionality is an anti-pattern. It’s the RDM that has been shown to be the real bad design approach.

Martin Fowler’s article makes various assumptions about what constitutes good data design:

  1. OO offers the ability to encapsulate state and only allow it to be accessed via an object’s methods.
  2. Procedural code couldn’t (so easily) encapsulate state in this way.
  3. OO is inherently better than procedural designs, as it can encapsulate state, tied to functionality. Thus, if a language supports objects, then they should be used to store state and functionality together. Failing to do so is an anti-pattern.
  4. This doesn’t just apply to domain models; any object that only contains data is “anaemic” as it fails to mix functionality and state.

Over the years, many have taken this article as gospel. Martin expresses the opinion that “anaemic” objects somehow aren’t “real OO” (“What’s worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about”) and thus an anti-pattern, and many blindly repeat this. So what is “real OO”? “Smalltalk” is one answer some will give. So whatever happened to Smalltalk; did it fail as a language because it was “too OO”? Java might be seen as a “real OO” language, but it has primitives and strings are immutable, “which reeks of functional programming” according to at least one person. So many argue it’s not. Some might claim that C# is a “real OO” language, but it has the same non-OO features as described above, plus it has value types (structs and enums) and events. Additionally, it has many functional-style features, such as lambdas, LINQ, static methods and the like. The list goes on with C++, Python, Ruby, JavaScript, F# (yes, it has classes) all having a mix of “OO” and “non-OO” features.

Does it really matter though? Isn’t the fact that all these languages mix and match programming paradigms a good thing? Their existence (and popularity compared to Smalltalk) would suggest so. Does it really make sense to talk in terms of “OO languages”, “procedural languages” and “functional languages”? Probably not. Anyone keeping tabs on what’s being suggested for implementation in C# 7, for example, will know that those corner-stones of functional programming – tuples, records and pattern matching – are the most popular features requested. Languages are becoming ever more “hybrid”, or “multi-paradigm” in nature.

There’s a good reason why languages, that might traditionally be seen as OO languages, are embracing functional features. The nature of how programs work is changing. Gone are the days of the simple, single-threaded, world. Now days, it’s all about sharing data between distributed, parallel processes, applications or even servers. The single biggest hurdle to this change is shared, mutable state. Various ideas have been tried over the years to overcome problems with shared, mutable state and all, save for one, have problems. That one way, ironically, is to get rid of it! Parts of the system have to have changing state, such as any user interface and any data store. Beyond that, there’s no actual need for state to change as it’s passed around the system.

The “Rich Domain Model” (RDM) is unfortunately built completely on the idea that we pass around state, and the means to change that state, coupled together. For example, we might expect an object that acts as a proxy to a database table to enable us to update it and thus update the table. The very core of the RDM contradicts the needs of modern, distributed, parallel systems; that core is quite rotten. If the core is rotten, then the whole model is rotten, thus RDM really is better seen as the Rotten Domain Model these days.

What well-designed modern systems have, is clusters of functionality, passing around immutable data. We have a separation of the data from the functionality: the two parts are abstracted away from each other. So far from being anaemic, the ADM is an abstracted solution that works well with distributed, parallel systems. The ADM, as the Abstracted Domain Model, has actually been proven to be the better system.

(The image used with this post is from

4 thoughts on “The Rotten Domain Model is dead; long live the Abstracted Domain Model

  1. vert.X and microservices, polyglot the only way to go, programming is the tool and protocol is the glue, take a look trust me you might like it

  2. I think there’s a misconception at the heart of this article. This misconception is the notion that Rich Domain Models are a special interest/lobby for pure OOP. These models are actually best developped using a multiparadigm language like C# or Java.

    Rich Domain Models are a specific part of an architecture doing specific things. It is bullet-proof but it is not everything for everything or an all or nothing thing like you try to convey.

    It’s hard to say it without sounding offensive, but like all critics of rich models I’ve ever met, you criticize things you do not understand.

    Saying that Rich Domain Models will disappear because of distributed computing is like saying that mathematics will disappear because of computers. This is how you sound to DDD experts.

    I don’t have the time to beat this something with something, so I’ll include my something by reference : Evans ‘book and Fowler’s article. And real world success, whole businesses transformed.

  3. Reddy,

    The problem with being an “expert” in anything to do with software is that you get left behind by new ideas. I see this in every developer I’ve met who claims to be an expert: they are a rich source of outdated knowledge. The measure of a good developer is that they are a perpetual beginner who is always learning something new.

    The idea that the ADM is an antipattern is an antiquated idea that’s had its time. Anyone, who falls into the “authority fallacy trap” of thinking words written by software celebrities years ago will always be right, is a fool.

  4. @reddy,

    I think “Tricky” sums it up nicely. Evans and Fowler are of course entitled to their opinions; as are you.

    However, the rotten domain model only makes sense if applied to an an old-school OO solution. Trying to bind data and functionality in distributed, non-OO paradigms is at best hard; at worst down-right pointless.

    Like Tricky, I’d argue that anyone who describes themselves as an expert when it comes to development has stopped learning and is falling behind the rest of us…

Comments are closed.