Introduction
Welcome to the first part of my Domain-Driven Design (DDD) series, where I share my experiences and lessons learned as I navigate the world of DDD. Through this series, I aim to break down complex concepts, reflect on my learning journey. In this first part, we’ll take a look at what DDD is, when to use DDD and what to learn.
DDD introduction
You may ask what DDD is and why we need it. Well, we design most of the software we develop for businesses.. Essentially, we are creating digital systems that replicate real-world business processes and activities. However, as developers, we find it challenging to fully understand business domains we haven’t been trained in. We also confine our thinking to project scopes, Jira tickets, and predefined tasks, without much encouragement to look beyond them. As a result, many projects go off track, ending up with cool features but ultimately fail to serve end users.
This is where Domain-Driven Design (DDD) plays a crucial role, helping us deepen our understanding of the domain when we start building new software or developing new features for existing projects.
DDD is “a philosophy for developing software systems that encourages domain thinking at every step of the Software Development Life Cycle (SDLC).”
DDD is a mindset that enhances developers’ understanding of business domains, on what they are doing. DDD doesn’t change how we code or the technologies we use. Instead, it reinforces this deeper understanding by encouraging the design of software models that closely reflect real-world business, ensuring alignment between code and business needs.
Should I use DDD for my project ?
If you’re looking for an answer to this question, you might come across the quote: ‘Probably 95% of all software applications fall into the “not so good for using DDD” category.’ A number that high might make it seem like there’s little reason to consider DDD at all. However, let’s challenge that perspective and see when and where DDD can be beneficial.
The statement was made more than a decade ago, and the software market has evolved significantly since then. Alongside data-centric software, we are now seeing a surge in applications that replicate real-world businesses across various industries, including banking, finance, sales, marketing, and education. If your app serves complex, constantly evolving real-world businesses and requires a deep understanding of business rules, then DDD becomes a suitable choice. And if you are building a data-centric application where the primary focus is on storing, processing, and retrieving data rather than modeling complex business behaviors, you can apply DDD as little as needed to benefit your project or follow the YAGNI (You Ain’t Gonna Need It) principle.
DDD is not an all-or-nothing approach. You can use DDD as little as needed. You don’t have to structure the entire application around DDD. In fact, sometimes only certain parts of your application benefit from it, while others can follow different architectures. This flexibility is one of DDD’s greatest strengths, enabling teams to balance design complexity with practicality without feeling compelled to use it unnecessarily. Therefore, before adopting DDD, you should understand your application’s purpose and identify which parts would benefit the most from it.
Should I use DDD for my project ?
The DDD concept diagram below is a great starting point for learning DDD.
First of all, you begin with Domain Discovery, and in my experience, if you are a developer, you should set aside technical thinking at this stage. Focusing on technical details too soon can lead to unnecessary complexity and confusion. After that, move to Software Architecture by focusing on bounded contexts. Finally at software design, learn about domain events, context mapping, aggregates.
Conclusion
In this article, we will explore what DDD is, when to consider using it, and its core concepts. See you in the next article that we will talk about Domain Discovery !
Would you like to read more articles by Tekos’s Team? Everything’s here.
References
Author
