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?
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.
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 Event Driven Architecture are easy or more difficult to integrate.
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.
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.
CQRS
The abbreviation stands for Command Query Responsibility Segregation. In short, it means that you separate the writing of data in your software design, where transactions are important to ensure integrity. And reading data, where that integrity has already been handled by writing. This leads to more autonomy and better performance of your system.
Event Storming
Event Storming is a way for business owners and IT developers to come up with a solution for a business goal together. In this meeting format we will work on Events, Business processes and recognize where we have to make important choices.
Event Sourcing
Sourcing events or storing and reading back events has a major advantage: going back to a previous version of your application is always possible because after each event you save exactly that: what has changed on my system and what caused that change.
Bounded Context
A core concept in DDD is bounded context. This is the area or better domain in which the same (business) rules apply and in which we agree on what we mean by the terms used in our business process.
Events
Events are important in a DDD environment. These are the things where we describe the behavior of our system. By using Events in a software design (Event Driven Architecture) you also ensure more autonomous systems. And that helps with your flexibility as a domain and shortening your time-to-market.