Learning Domain-Driven Design (DDD) — Part 1
Everyone talks about DDD, but how many understand and correctly apply Domain-Driven Design? I want to be one of them.
Warning: This is an experiment!
I see myself as a shy, mostly self-doubtful, software engineer and I feel not comfortable learning something in public. I am a slave to the stereotype of the software engineer that must know everything.
I want to change. I admit my ignorance in public.
As Freddie Mercury once said: “I want to break free”. Here I am.
I am not perfect. I do not know everything. I have to study a lot.
Having told you so, one of my current topics of interest is Domain Driven Design. I admit I do not have a clear picture of this topic even if I should.
This year, I will attend the DDD Europe conference in Amsterdam. I decided to attend this conference because I heard this term a lot in my field but I think I do not truly understand its meaning. I want to get there ready to grasp every bit of information and come back home as a better software engineer that knows a lot about that topic. To be prepared for that, I decided to make a little experiment with myself.
I want to test the Feynman Technique. If you do not know this technique here on Medium there are plenty of articles about it. Basically, it says that to truly learn something it is useful to explain it to someone else. Even better, if you can explain it in simple terms.
Moreover, since I am starting to have some followers that may be interested in this topic, I want to publicly share what I am learning during this journey. It would be amazing if even one of them would find these articles as a motivation or an inspiration to do the same.
Let’s get into the interesting stuff. Today, I received a beautiful copy of Learning Domain-Driven Design¹ by Vlad Khononov. If you, Vlad, are somehow reading this, thank you for having written this book. I chose this book to understand better this approach.
As for now, I have read just the foreword and the introduction. I was too excited to start this experiment to wait for the end of the first chapter 😆
Even in the introduction, I have understood that DDD is a collaborative approach, and for that communication is key. Additionally, I have found an interesting concept: the difference between strategic and tactical tools.
Strategic tools of DDD are used to know more about the business domain and have a common ground for interpreting the business among different stakeholders.
Tactical tools are more related to the code: how to structure the code, which names you have to use, and so on. This is useful to keep the engineers away from using their own jargon, which may create a gap between them and the business guys.
Everything has the purpose of easing the communication between the business guys and the engineers. If they can understand each other better, if they can speak the same language, they can create amazing products.
I hope you will follow me and be an active part of this journey to mastering Domain-Driven Design. I would love to have some feedback from you.
Do you know some videos, some courses, or some other books that I may use as a reference to truly understand this subject? I am waiting for your suggestions! 💚
References
[1]: Learning Domain-Driven Design by Vlad Khononov (O’Reilly). Copyright 2022 Vladislav Khononov, 978–1–098–10012–1
