· oop altnetuk ddd eric-evans

Similarities between Domain Driven Design & Object Oriented Programming


The similarities

Anaemic Domain Model/Law of Demeter

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. ~~~csharp object.GetSomething().GetSomethingElse().GetSomethingElse() ~~~ 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.

Side Effect Free Functions/Command Query Separation

An operation that computes and returns a result without observable side effects ... The developer calling an operation must understand its implementation and the implementation of all its delegations in order to anticipate the result.
My colleague Kris Kemper talks about a very similar OOP best practice called command query separation. From Martin Fowler's description:
The really valuable idea in this principle is that it's extremely handy if you can clearly separate methods that change state from those that don't. This is because you can use queries in many situations with much more confidence, introducing them anywhere, changing their order.
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/Meaningful Naming

A design in which the names of classes, methods, and other elements convey both the original developer's purpose in creating them and their value to a client developer. ... If a developer must consider the implementation of a component in order to use it, the value of encapsulation is lost.
In OOP this would be described as using meaningful names as detailed in Uncle Bob's Clean Code (my review).

Bounded Context/Clean Boundaries

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:
Code at the boundaries needs clear separation and tests that define expectations
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.

Anti Corruption Layer/Wrappers

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.

Domain Driven Design = Object Oriented Programming + Ubiquitous Language?



From Wikipedia’s Object Oriented Programming entry:






Why the dismissal of DDD?

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.


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.




  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket