How to Design OOP Well
I'm no expert on Domain-Driven Design (DDD), but as far as I can tell, it's just a fancy term for doing OOP well.
But what does "doing OOP well" even mean? I think it boils down to this:
You have to divide things just right.
You have to group things just right.
The groups have to send messages to each other just right.
And that messaging needs to be performant, secure, and stable.
I know you might hate that phrase, "just right." It sounds vague. But I believe that single phrase is the very essence of design.
Everything is a Trade-off
There are no silver bullets in software. No flawless solutions, no magic answers that fix everything. Every choice is a trade-off, which means you have to analyze the situation and find the most "just right" solution for the context.
I didn't make this up; this is what architects always say.
The hardest part of project design is this fundamental nature of software. Since there are no objective criteria for "just right," your choices will always be subjective.
Take OOP, for example:
You divide business logic just right, according to the requirements.
You group business logic just right, according to the requirements.
The boundaries communicate just right, according to the requirements.
You implement robust communication just right, according to the requirements.
DDD acts as the guidebook that helps you establish the criteria for 'just right'.
The Subject of DDD
Let's state it again: software is about making money. To make money, you have to satisfy your users. To satisfy your users, you have to fulfill their requirements.
Therefore, DDD starts with getting as specific as possible about the requirements through communication with the customer. And to do that, you first need smooth communication.
That's why DDD defines what's called a Ubiquitous Language.
In simple terms: developers should primarily use the language that the business experts use.
You know that one tech guy who insists on using overly technical terms and jargon for no reason? It's annoying as hell, right? It's the same feeling. You don't want to talk to people who deliberately use difficult language when it's not necessary.
That's exactly how the customer feels. They're trying to explain what they want, and the developers are mixing in programming terms. The customer can't understand a thing and just gets frustrated.
On the flip side, developers have to fully understand the context behind the customer's requirements. We call this the Domain. If you don't understand the business, you can't understand the business's terminology.
The Ubiquitous Language is the shared vocabulary that everyone—developers and customers alike—agrees to use to ensure smooth communication. It's the process of using these defined terms in your requirements docs, and even in your code, to eliminate any chance of misunderstanding.
Dividing and Grouping 'Just Right'
Once you've defined the Ubiquitous Language, you start dividing the entire business into domains of responsibility.
A popular method for this is Event Storming, but I'm not gonna explain it here. Just look it up. It's a workshop where not just developers, but customers too, get together and map things out. Sometimes you divide based on data, sometimes based on ownership. For the details, check out a book on DDD.
Once you've drawn the boundaries for the business logic, you have to group the related things inside. Of course, the trick here is also to group them "just right." Usually, you group things based on transactional consistency. And you pick one object in the bundle to be the "representative" or "gateway" for the group. This is the Aggregate and Aggregate Root.
When these groups communicate, they use this gateway as the standard. This naturally allows you to achieve the OOP goals of:
- Communicating between boundaries according to requirements.
- Implementing robust communication according to requirements.
Conclusion
The Ubiquitous Language solved the problem of communication, which was plagued by misunderstandings and assumptions, and clarified the essence of the requirements.
The Bounded Context gave us clear criteria—'responsibility and language'—to divide a massive business "just right."
The Aggregate provided a standard for grouping related concepts "just right" within those boundaries, based on the principle of 'data consistency.'
The Aggregate Root opened a path for these well-divided and grouped units of responsibility to communicate safely through a clear 'gateway,' without treading on each other's toes.
This is how DDD helps you design OOP well.
Top comments (0)