DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for A gentle introduction to Domain Driven Design
The Lone Architect
The Lone Architect

Posted on • Originally published at Medium

A gentle introduction to Domain Driven Design

Starting into DDD is hard, even though it’s heavily praised by their practitioners. The topic is widely covered in the now infamous β€œDomain Driven Design” by Eric Evans (Blue Book) and β€œImplementing Domain Driven Design” by Vaughn Vernon (Red Book).

Both of them are terribly verbose and thick, which is no surprise coming from Java engineers. The material is dense and there’s a lot of noise around the main ideas, which makes the barrier to entry even bigger for newcomers. Many times, I’ve felt like i’m too stupid to understand what StackOverflow made obvious after few researches.

Although the verbatim is complex, the ideas behind are rather simple and easy to grasp. When it β€œticks”, it just becomes common sense.

It’s all about the business

Image description

Here’s the main gist : domain model should be kept separate from the dangers of the outside world, and interfaces are the bridges connecting the dots. That’s also the basis for Hexagonal Architecture, Clean Architecture, Onion Architecture, and all the other trademarked terms that more or less boil down to the same principles.

They are all domain centric.

But Domain Driven Design takes it a step further and gives the tool to structure and develop the domain itself, while the others architectures are just a mean to encapsulate the domain. In other words, you can do Hexagonal without DDD, but you can’t really do DDD without layers around.

I believe both the blue & red books are opaque about it. You’ll be tempted to believe you either go DDD or you don’t, there’s no in-between. Which is the reason I’ve been discouraged from trying DDD altogether.

But Vlad Khononov took another approach. In his book β€œLearning Domain-Driven Design” (affiliated link), he starts with the very basic and foundational principles of DDD, which are Subdomains, Bounded Contexts and Aggregates. He then establish a scale of usability. Depending on the task at hand, you might not need to do DDD. For once, a book that introduces DDD and isn’t all-in.

One shouldn’t use a complex tool for a trivial problem.

I loved this approach and found it more genuine and useful than the other two books. Let’s see how it unfolds.

Disclaimer

I am by no mean a DDD guru or expert, but rather a learner who condensed his knowledge inside this article. I hope to provide the kind of introduction I wish I had when I started this adventure. DDD is a complicated topic, so always double check your assumptions.

πŸ‘‰ Read the rest of the Article on Medium

Top comments (0)

11 Tips That Make You a Better Typescript Programmer

1 Think in {Set}

Type is an everyday concept to programmers, but it’s surprisingly difficult to define it succinctly. I find it helpful to use Set as a conceptual model instead.

#2 Understand declared type and narrowed type

One extremely powerful typescript feature is automatic type narrowing based on control flow. This means a variable has two types associated with it at any specific point of code location: a declaration type and a narrowed type.

#3 Use discriminated union instead of optional fields

...

Read the whole post now!