This will be a series of tutorials taking you through how to apply Domain Driven Design (DDD) in a practical manner using C#. By the end of the series, we will have a program of some sort that simulates a domain discussed further down.
Before we get started with the fun coding bits (they will be in part 2), let us go through what DDD is.
What is Domain Driven Design?
DDD is an approach to software development where the key driver is the modelling and understanding of a particular domain in order to better design and implement software.
It is a methodology that involves creating a shared understanding of a domain and a common language for communicating about it among the stakeholders, which can lead to more effective communication and a more robust and maintainable software design.
What is a domain?
Every software program relates to some activity or interest of its user. That subject area to which the user applies the program is the domain of the program.
Domain Driven Design - Eric Evans
Simply put, the domain is whatever your program is trying to model. If you are creating a program to help do shipping then logistics is your domain. For trading, finance might be your domain.
Getting started
If you were to go over DDD from start to finish, there would be a lot to cover. The original book is just over 500 pages and it is quite a dry read. Some of it you may never get to practically use although I would still recommend trying to pick up a copy of the book if you are interested.
In this set of DDD walkthroughs though I will be going through how I personally approach a new problem or domain. It will not cover everything from the book and may include some things that are not present in the book as well, such as event storming.
Something fun to model
You have probably noticed that a lot of walkthroughs for new frameworks or techniques use the good old "todo" application. Honestly, it is a bit boring and there is not a lot to it. So instead I'm going to attempt to model something I at least have some interest in...
Apologies upfront if this has immediately turned you off but honestly you do not have to like Pokémon to continue reading. Most people will work at places where the domain they are modelling is not something they are a fan of or know anything about in the first place.
What we are going to try and do is model at least the simplest parts of the Pokémon game.
A simple model
Usually, my jumping-off point here would be to ask questions to someone with great knowledge of the domain to tell me how things work. I am not by any means a Pokémon expert so I will be relying on the great arbiters of knowledge that are Google and Bulbapedia to help with explanations.
So let us pretend (or not) that you know nothing about the Pokémon games. Here is the very basics of how the games work.
You are a trainer
You can catch many Pokémon which are tracked in a Pokédex
You have a team of Pokémon that you use to battle other trainers who have their own teams
At its very core, that is all there is to it. There are lots of things I've missed off here such a Pokémon leagues, regions, breeding and others which we will talk about if and when we get to them.
The reason I have highlighted the words above is that we are already starting to see distinct things in the domain we want to model. These words and phrases will build up our ubiquitous language.
A language structured around the domain model used by all team members to connect all activities of the team with the software
Simply put, the way we talk about things in the domain should be consistent and reflected in the software. If some people are calling say trainers by two different names, it is likely to cause confusion and could end up with messy software over time. I am sure most have run into software where a particular resource used to be called one thing and was later renamed but lots of references to it by its old name are still all over the place.
But let's look at what we have so far
| Term | Description |
| Pokémon | A pocket monster. Trainers catch these and can use them as part of their team to battle other trainers. |
| Pokédex | A device that is used for tracking which Pokémon a trainer has seen or captured. |
| Trainer | Catches Pokémon and has a team which they use to battle other trainers. |
| Team | A collection of Pokémon used by trainers for battling. |
| Battle | A competition between two teams of Pokémon. |
A good start. We can already start to build up a diagram of how these entities relate to each other.
Not perfect but simple enough!
Coming up next
I will leave it there for this tutorial but in the next tutorial, we will start modelling these in code using some DDD techniques such as using aggregates, repositories, value objects and more!
If there is anything you would like to see or anything you think needs improving or changing in this article, please let me know. I will be happy to amend it the article with thanks 🙂