Patterns are an integral part of human behaviour and the world around us, they heavily influence how our brains work and how mathematics and communication work; it’s in our DNA. Domain Driven Design (DDD) is a set of clear patterns which you can utilise, not only for coding but also analysis and design.

gravity9 Founding Partner and Lead Consultant, Noel Ady explains his love affair with DDD. I’ve been building custom software for business and organizations for over 20 years and I’ve seen both successes and failures in that time. There are some common traits for those projects that succeed over the ones that fail. Primarily, build only when you need to as there are a plethora of services available to us today through multiple cloud platforms. However, when you do build, stand firmly on the shoulders of giants. By that I mean use proven patterns and practices to help you deliver predictable and quality solutions.

From my experience, working with DDD principles leads to success and, not just from a functional perspective. Well written and designed code is not only easier to maintain and understand, but it can also keep you out of a corner. Time and time again my teams have been rewarded with praise at key transition or change points in a project, where new information arrives and requires a change in direction or logic or both for a given solution which may be partly implemented. Although these points may seem insignificant, having options, at all levels of your code base, provides solution flexibility which will result in far fewer rewrites of code saving both time and money instils confidence in the delivery team.
This all sounds good, however, one problem with DDD is that it is hard. It’s hard to get the concepts and it takes a good part of an individual’s career to both understand the principles and master those in practice. Figure 1.0 shows a what I consider to be the pyramid of essential skills to truly master building well designed DDD solutions.

At gravity9, we place an emphasis on experience for this very reason. In order to truly design and build effective solutions (whether you use DDD or not) experience and skills will always play a part in successful outcomes. Combining skills, experience and DDD, delivers repeatable, predictable successful outcomes. And, in fact, the output solution code is generally much more readable and maintainable to most programmers even without the DDD core. To me, that’s is the key benefit of driving development this way, you end up with code that truly reflects your business. There is code complexity but it is an intentional type of complexity that can be trained and documented so support and enhancement developers are able to quickly understand it quicker than having to grasp a code base with no inherent structure and quality DNA.

So where does it help?
DDD is not a new concept, it was born through the great mind and thinking of Eric Evans at the start of the century. Eric Evans’ ‘blue book’ published in 2003, although a little dated now, has been at the heart of many modern design concepts. And many other authors have built on the early text.

The initial text was split in two, (what we think of as the macro and the micro). The first half explains principles around designs and analysis; splitting an organisation down by sub-domains and aligning current and future state systems that support those sub-domains as bounded contexts. This is an excellent way to draw logical lines over your business and application landscape. It allows you to divide and conquer the big complex ‘real world’ and start to break it down to something more manageable. We can now begin to discuss smaller areas of the business in their own context and vocabulary in order to gain clarity. This approach on its own is incredibly powerful and helps us decide on fundamentals such as ‘build vs buy’ or begin to look at the granularity of micro service design.

The second section provides a whole host of principles around development and how to represent your domain design in code. When mastered, these techniques provide a full toolbox of patterns and practices which, in my experience, can solve just about any solution with elegance. These principles provide guidance on how to define your code to best serve the behaviour required- a key aspect! DDD is behaviour centric, it tries hard to keep you from designing to entities and pushes you more to design around behaviour, which I believe is better as data is a by-product of behaviour. That’s not to say data isn’t vastly important, but when you build behaviour first, you can build data views and aggregates much easier than vice versa, where data is the driver and behaviour has to sit around it.

When you build for behaviour, you are more aligned to building something to reflect real life, as opposed to building to data and entities, which doesn’t serve well when trying to organise manage true complexity.

I strongly believe the most effective digital transformation strategy is to build a platform to embrace change. DDD has proven itself to be a fundamental agent in that recipe for a solid foundation to stretch and morph to your business needs without having to compromise on maintainability and code / architecture quality.

To find out more about the gravity9 love affair with Domain Driven Design or to speak to the team about a project visit the contact us page on our website or email hello@gravity9solutions.com
‍