Backend Beginners: Don't Start with DDD

This is an opinion piece.

Conclusion

It is pointless to learn DDD without first learning modeling.

In Detail

As the name implies, DDD (Domain-Driven Design) is a development methodology where you first define a domain model and then move to implementation. The purpose of a domain model is to improve the maintainability of a system by unifying the business conceptual model with the internal system model. (The logic is that since business requirements generally evolve along the lines of the business model, the system becomes easier to change if it also aligns with that model.) In other words, modeling skills are essential.

Three years ago, I started buying books on DDD and "Implementing DDD," reading through them without fully understanding. I deepened my understanding through books by Mr. Masuda, Mr. Naruse, and Mr. Matsuoka. Following the DDD books, I tried talking to domain experts and drawing domain model diagrams. However, those domain model diagrams were drawn in a non-standard class diagram notation, with some types becoming like isolated islands that didn't connect to other types, and they were far removed from the actual implementation. (I was desperately trying to figure out which ones were aggregates.)

It was then that I happened to read books on UML modeling.

• Introduction to UML Modeling
• UML Modeling Lesson

From that point, the fog that had been hanging over me cleared. When I understood modeling patterns like "plans and results," "headers and details," and "events," I realized why my domain model diagrams weren't working. I simply lacked modeling skills to begin with. You don't have to think about aggregates from the start; when you perform conceptual modeling, aggregates emerge naturally, and it becomes easier to find clean boundaries.

I cannot show the details, but here are the domain model diagrams from before and after learning UML modeling. The one on the left is before, and the one on the right is after.

Since then, I have been able to apply object-oriented strengths like plugins and their design patterns.

• Introduction to Design Patterns in Java
• Design Patterns Explained: A New Perspective on Object-Oriented Design

It was then that I first realized. DDD is a level of practice that can only be reached with a foundation in both object-oriented design and conceptual modeling. If I had learned these first without jumping straight into DDD, things would have likely gone much more smoothly. It took me three years to realize this. So, I dedicate this opinion piece to you so that you do not make the same mistakes as I did.

Other Notes

There are often discussions about the Repository pattern or Entities, but those are ultimately a collection of practices for preparing a blank canvas—free from the influence of databases or frameworks—so that the domain model can be realized within the system (allowing you to draw the domain model freely on that canvas). If you are more interested in those practices than in the model itself, I recommend reading books on Clean Architecture. You can deepen your understanding without necessarily using the term DDD.