Learning Domain-Driven Design (DDD) — Part 5
My Perspective about Domain-Driven Design and its complexity
This first part of my Domain-Driven Design learning journey about the basics of the framework terminology makes me wonder A LOT.
I was about to write another beautiful article on the difference between Bounded Contexts and Business Subdomains, but then I stopped, zoomed out a bit, and thought about how convoluted this model is, and how simple the world can be in some scenarios.
From my (at the moment, not very wide) perspective, all of these terminologies and technicalities remind me of a sort of “overengineering” of concepts about software design.
During these days my mind has been flooded with strange concepts like:
- Business Subdomains and their types (Core, Generic, Supporting);
- Ubiquitous Language;
- Bounded Contexts.
They are very complex models for describing very simple real-life problems in software design.
Should software design require a so complex analysis? Should everyone learn this bizarre and convolute terminology to be proficient in their job?
The answer that I think I can give you right now is it depends.
In my opinion, it depends on the size of your company. It depends on the complexity of the problem you are going to tackle. It depends on the level of maturity or stage of development of your business.
Otherwise, this seems to me more of an obstacle than a methodology that can lead you to awesome results.
Just to picture what I am talking about, if you are developing a Minimum Viable Product (MVP) for your startup, Domain-Driven Design would not be your best choice.
Moreover, I think, in some situations, can be better to have a critical perspective on it. Often, it could be more effective to take some concepts and not apply the whole DDD like a religion.
On the other hand, if you have a complex business, and many teams, following the principles of Domain-Driven Design can help you define boundaries.
These boundaries can help you write better software, deliver the right product, and better maintain your service. It helps assign clear ownership of pieces of your software, thus avoiding confusion that can lead to poor quality and unmaintained systems.
To wrap up, I can say that learning this framework is worth the effort. Knowing these concepts helps you even if you do not need them. You know the framework, you know its tools, and you are aware of what you can use and what it can just waste your time and energy.
Moreover, if your business grows you are prepared, and you know how to tackle the complexity you will have to face.
Anyway, I am extremely curious about your stories, points of view, and experience on this topic.
This is the fifth chapter of my journey in Learning Domain-Driven Design.
I hope you want to actively participate in this journey to mastering Domain-Driven Design. I would love to hear some feedback from you.
Do you know some videos, courses, or other books that I may refer to truly understand this subject? I am waiting for your suggestions! 💚
These are the previous articles I have written about this topic:
