Buzzword Buster – DDD

Definition:

Domain Driven Design (DDD) is an approach to software design which puts the focus on the problem domain and provides a structure for making design decisions to accelerates software development for complicated domains. The key components in DDD include:

Domain: the subject area to which your program is applied

Model: abstractions that describe aspects of a domain and can be used to solve problems related to that domain

Domain Experts: people with the most complete knowledge about the world your system will live in

Ubiquitous language: a language around the domain model used by all team members, the language is ubiquitous because it is present everywhere

Purpose:

Traditionally .Net applications are developed using a data-centric approach where you build your system around your understanding of the data – creating all the tables and the relationships in the Database and then mirror them in your .Net code. This approach is popular because of the ease and speed with which you can create a fully functional system from the ground up.

DDD on the other hand, focuses on the problem domain as a whole which covers not only the data but also the behaviour. DDD encourages greater involvement from domain experts, the idea is to build your system in a manner that’s reflective of the actual problem domain you are trying to solve and let the domain drive your design decisions.

One of the greatest challenges in developing a new system is to learn and understand the new business, which is why a single, shared language (the ubiquitous language) between the users and the developers can go a long way to reduce misinterpretations and create a more concise and effective communication amongst all interested parties.

Parting thoughts…

It is important to remember that whilst DDD is better than the data-centric approach in some cases, the reverse is also true.

Also, DDD carries with it the overhead on the developers’ part to become proficient (or sometimes experts!) in the problem domain and being able to communicate with the users in an common language.

Mastering both programming skills and business knowledge in the core problem domain is difficult and takes significantly longer than the course of developing an application – seasoned developers in the Financial sector would no doubt agree with this! This is one of the reasons why knowledge in a particular area (equities, derivatives, etc.) is such a valuable asset and developers who also qualify as domain experts in a business area are so highly sought after and compensated.

On the hand, it is also why so many find it hard to break into Finance despite boasting impressive development skills, and why many others become typecast with a specific industry/area and find opportunities outside their familiar territories hard to come by.

During my time with Credit Suisse I have come across many developers who have spent their entire professional career in the same business area, becoming domain experts in their own right. Though personally it’s not what I’m looking to get out of my career I can definitely see the merits of doing so and appreciate the enthusiasm they have for their problem domains.

Further reading:

Domain Driven Design by Eric Evans