There was quite a bit of discussion in the session about anaemic domain models.

An anaemic domain model is one where a lot of the objects are merely data holders and do not actually have any behaviour inside them. While it has a fancy name, in OO terms this problem materialises due to our failure to adhere to the Law of Demeter.

My colleague Dan Manges has a brilliant post describing this principle but a tell tale sign is that if you see code like the following in your code base then you’re probably breaking it.

This is often referred to as train wreck code and comes from breaking the idea of Tell Don’t Ask. In essence we should not be asking an object for its data and then performing operations on that data, we should be telling the object what we want it to do.

DDD talks about side effect free functions which are described as follows:

My colleague Kris Kemper talks about a very similar OOP best practice called command query separation. From Martin Fowler’s description:

It’s not exactly the same but they have a shared intention - helping to make the code read more intuitively so that we can understand what it does without having to read all of the implementation details.

Intention Revealing Interfaces describe a similar concept to Side Effect Free Functions although they address it slightly differently:

In OOP this would be described as using meaningful names as detailed in Uncle Bob’s Clean Code (my review).

DDD’s bounded context describes "The delimited applicability of a particular model" i.e. the context in which is is held valid.

This is quite closely related to the idea of clean boundaries in Clean Code where Uncle Bob states:

In both cases we are creating an explicit separation of 'our code' from the outside world so to speak. We want to clearly define where 'our world' ends by defining the interfaces with which we interact with the outside world.

The anti corruption layer in DDD is "an isolating layer to provide clients with functionality in terms of their own domain model."

It is used to create a boundary for our bounded context so that the models of other systems we interact with doesn’t creep into our system.

This is implemented in OO using one of the wrapper patterns. Examples of these are the Facade, Adapter, or Gateway pattern which all solve the problem in slightly different ways.

The intention in all cases is to have one area of our code which calls 3rd party libraries and shields the rest of the code from them.

While talking through some of these ideas I started to come to the conclusion that maybe the ideas that DDD describe are in fact very similar to those that OOP originally set out to describe.

The bit that DDD gives us which has perhaps been forgotten in OOP over time is describing the interactions in our systems in terms of the business problem which we are trying to solve i.e. the Ubiquitous Language.

From Wikipedia’s Object Oriented Programming entry:

The second idea of physical modeling seems to have got lost somewhere along the way and we often end up with code that describes a problem at a very low level. Instead of describing a business process we describe the technical solution to it. You can be writing OO code and still not have your objects representing the terms that the business uses.

There are some things that DDD has certainly made clearer than OOP has managed. Certainly the first part of the book which talks about building a business driven Domain Model is something which we don’t pay enough attention to when using OOP.

For me personally before I read the concepts of DDD I would derive a model that I thought worked and then rarely go back and re-look at it to see if it was actually accurate. Reading DDD has made me aware that this is vital otherwise you eventually end up translating between what the code says and what the business says.

Ideas around maintaining model integrity are also an area I don’t think would necessarily be covered in OOP although some of the implementations use OOP ideas so they are not that dissimilar.

The reason I decided to explore the similarities between these two concepts wasn’t to dismiss Domain Driven Design - I think the framework it has given us for describing good software design is very useful.

Clearly I have not mapped every single DDD concept to an equivalent in OOP. I think DDD has given a name or term to some things that we may just take for granted in OOP. Certainly the DDD ideas expressed around the design of our model are all good OOP techniques that may not be explicitly stated anywhere.

I wanted to point out these similarities as I feel it can help to reduce the fear of adopting a new concept if we know it has some things in common with what we already know - if a developer knows how to write OO code and knows design concepts very well then the likelihood is that the leap to DDD will not actually be that great.

It would be really good if we could get to the stage where when we teach the concepts of OOP we can do so in a way that emphasises that the objects we create should be closely linked to the business domain and are not just arbitrary choices made by the developers on the team.

Maybe the greatest thing about DDD is that it has brought all these ideas together in one place and made them more visible to practitioners.

I am very interested in how different things overlap, what we can learn from these intersections and what things they have in common. It’s not about the name of the concept for me, but learning what the best way to deliver software and then to maintain that software after it has been delivered.