boundaries of your systemβs microservices? Have you been slowed down by the technical complexity of your codebase? Has your team been stepping on each otherβs toes? If your answers to any of these questions are yes, then applying Domain Driven Design to your microservices is likely to be useful to your team.
One of the difficult choices in microservices architecture is coming up with boundaries and deciding whether a particular piece of code should be turned into a microservice. Technical teams often make this decision without taking a business perspective on what really makes sense. Using DDD the boundaries for microservices are better designed by bringing both technical and business teams together to achieve the projectβs goals.
This book takes key concepts from DDD and applies them to microservices architecture. Using an example business domain, and end-to-end code examples, youβll learn to design and implement microservices using DDD. Youβll also understand DDDβs relationships to data mesh, team topologies, and micro-frontends. Bring technical and business teams together and achieve your projectβs goals.
The term Domain-Driven Design (DDD) was coined by Eric Evans in his seminal book, Domain-Driven Design: Tackling Complexity in the Heart of Software, published in 2003, and was well ahead of its time. In recent years, microservice architecture has gained a lot of attention as one of the most popular evolutionary architecture styles. DDD is an immensely useful tool for designing scalable systems/platforms and a solid basis for designing better microservices architecture. DDD is also useful for building distributed data architectures including data mesh, and for organizing a large team using team topologies.