The Anemic Domain Model and Functional Programming




Jöns gillar att veta varför man ska göra saker på ett visst sätt. Och så gillar han kaffe. Och gasbrännare.


Legacy Management and Legacy Code 29th July, 2017

Introducing Scaffolding Tests 01st December, 2016

Getting Things Straight

The Anemic Domain Model and Functional Programming

Posted on .

As I fascinated wander about in functional programming-land, one of the things that strike me the most is the clear separation of data and functions, the same thing that in the country of object orientation is called the anemic domain model anti-pattern

How come that a practice that in the OO community is very much frown upon, is exactly what functional programming aficionados embrace?

After some Google-fu practise, I think there is a historical explanation, coupled to a more esoteric, metaphysical (did I just say “metaphysical”?) one. And last but certainly not least, I think it’s due to the (shortcomings of?) the programming languages we use.

The Historical Reason

Starting with the historical reason, functional programming has its root in mathematics, where functions are everything. Of course you must have data to feed the functions with, but that data are very much external to the functions.

Combining data and functions in objects was first introduced in Simula in the mid 60’s. Simula was used for simulation, and objects were a way to combine data and functions to create small, self sufficient structures that could simulate real life artifacts.

After simulations came user interfaces. Object oriented techniques were a good fit when screens went from showing ascii to graphics. Objects could be made to draw themselves on the screen, and use their individual functions to react on other objects. And hey! They could even send messages to each other, i.e use each other’s functions!

The Metaphysical Reason

Intervened with these historical and practical reasons are the different ways to look at the world. When using an object oriented language, we try to view the world as “things” that “do” stuff, which we represent as classes with methods.

A functional view of the world when it comes to modelling, is more like seeing these “things” as concepts that almost entirely are defined by the functions that we chose should apply to them.

The Language Support Reason

Lasty, we have the programming languages themselves. Just like the saying “If all you have is a hammer, everything looks like a nail”, the way we model, and the patterns we use, are contextual to the language we use. Different languages make some things simple, other hard. Some ways to use a specific language will often lead to more complex solutions, some will more often than not lead to simpler ones.

So …

So, all in all, from an object oriented viewpoint, the anemic mode is an anti-pattern because it breaks the traditional object oriented way to model the world. It will also let the domain logic spread all over the code base, being hard to find as there is (probably) no support in the language for not combining data and functions in a sensible way.

On the other hand, from a functional viewpoint, the separation of data and functions is a good pattern as it complies to the functional way of modelling the world, and the language most certainly has good support for it.



Jöns gillar att veta varför man ska göra saker på ett visst sätt. Och så gillar han kaffe. Och gasbrännare.

There are no comments.

View Comments (0) ...