All software systems are hopefully designed to solve a real world problem. To be able to do this, the software needs an abstraction of the problem - a model - that it can work with. Coming up with this model is not always easy, especially if the real world problem is complex.
Domain Driven Design (DDD) is a software design process that can help us come up with the model. It gives us the tools and building blocks necessary to discover and design our model and turn it into working code.
The most important deliverables of the DDD process are the shared understanding of the problem domain and a language to describe it in. If you cannot describe the concepts and processes of the problem you are solving in such a way that everybody - both customers and developers - understand them, then something is missing from your model and you need to find out what it is. Exactly how you document this understanding and this language is less important as long as it works for your project. My personal favorite is to use UML diagrams and a wiki, but there are other alternatives as well.
In the DDD webinar, we are demonstrating what the domain modeling process might look like in practice. We re-enact a scenario where a designer and a domain expert (the customer) discuss a specific business problem while documenting the domain model in UML on an iPad. The key here is to keep the technical stuff on such a level that everybody involved understands the model, including the customer who in many cases does not know much about software development.
We also add some UX design to the process, since we have found that this forces us to look at the problem domain from a different angle and discover things that we would otherwise have missed (which we also try to show in the webinar). The end result is a feedback loop where the domain model, the UX design and the discussion with the domain expert all influence each other, gradually building up the understanding of the problem until we know enough to actually solve it in code.
DDD also includes patterns for designing and implementing the software. You may have heard about concepts such as entities, value objects, aggregates, repositories and services. We are not covering them in this webinar, but I tried to use them when I wrote the example code.
Finally, you do not need to go all in to be able to gain from DDD. Full DDD requires practice to master it and I still consider myself a beginner in this subject. In spite of this, the principles of DDD have helped us in many projects. For example, there was one deteriorating project where we experienced serious data consistency issues. Data was duplicated or not saved at all and optimistic locking errors occurred seemingly at random. We managed to bring the project back on track by restructuring our code to use entities, value objects, aggregates and repositories. With this I want to encourage you to familiarize yourself with DDD and pick the bits and pieces you feel might be useful to your particular project.
If you want to learn more about DDD, have a look at these resources:
- The book that started it all: Domain Driven Design by Eric Evans. If you really want to start using DDD in your projects, this book should be in your bookshelf.
- If you don’t have time to read the entire DDD book, or you need something right now, you can download and read this free, short summary of the fundamentals of DDD.
If you prefer watching and listening to reading, you can check out these talks on YouTube (in addition to our webinar, of course):