top of page
Werken op laptop

What is Domain Driven Design?

Domain-driven design reduces the distance between your business goals and IT support. 
By organising yourself differently, you understand each other faster and better! How great is that?

Download the DDD Jargon Booklet now

Our handy guide full of clear explanations of the most commonly used terms in the DDD world and a fun quiz to test your DDD knowledge.

Don't miss it and download it for free now!

Start your DDD enabling!

drie mensen staan in een lege ruimte voor een raam in een hoog gebouw, uitkijkend op de skyline van een stad

What is DDD?

Domain Driven Design represents a methodology that goes beyond software or system design. It actually touches your business. DDD is based on a division of your organisation around your business processes and therefore also your (software) applications. You will learn how that works during our DDD Basics training course

The core of Domain Driven Design

At the heart of DDD is the so-called "ubiquitous language". This means that everyone involved in a domain speaks the same language. Terms like user, offer, price, customer, etc. mean exactly the same thing to everyone in that domain. In another domain, terms may be defined differently.

This is important because it prevents confusion between what the business means and what IT builds. A concrete example is the selling price, which in the Sales domain is made up of elements such as cost price, mark-ups, etc. while that same selling price in the Marketing domain is nothing more than a number to display in an expression.

Want to get concrete and practical tools to implement DDD? Check out our DDD Basics and Next Level training courses.

DDD in practice

Domain Driven Design touches the whole organisation and that means you have to implement it carefully. Normally, you start from two sides, the business side and the IT side of one domain.

Both engage in conversation to discover things like bounded contexts, aggregates etc. Analysis of current systems is part of this to see if things like CQRS (command query responsibility segregation) or Events are easy or more difficult to integrate.

Lachend

DDD Roles

Within the DDD methodology, there are different roles: DDD Enabler, Agile Coach, Software Architect, Product Manager or Owner. And, of course, the developers in the development team. Learn more about what these roles mean in practice in our DDD training courses.

Advantages DDD

NLW voordelen DDD EN.jpg

Domain Driven Design, CQRS, Event Storming, Event Sourcing, Bounded Context, Events

All terms covered in our training courses. The Basics training is mainly about understanding these terms. And in the Next Level training we mainly focus on how to apply this in your system design and code.

 Do you want to make your organization more flexible and increase customer satisfaction? Register for one of our training courses.

bottom of page