Have you been finding it difficult to model 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 answers to any or many of such questions are yes, then Domain Driven Design is likely to be useful to your Team!

What is Domain Driven Design aka DDD

Domain-Driven Design is a language and domain-centric approach to software design for complex problem domains.

It consists of collective wisdom from Software Industry, collection of patterns, principles and practices that will enable teams to focus on what is core to the success of the business while crafting software that manages complexity in both the technical and business spaces.

The term was coined by Eric Evans in his seminal book “Domain-Driven Design: Tackling Complexity in the Heart of Software” written in 2003 and was well ahead of its time!

It started becoming very relevant with microservices architecture era. It was relevant in 2003 for designing modular monolith and today as well! Modular monolith is a topic for my other blog!

Tactical and Strategic patterns of DDD

We will use example of retail e-commerce domain to explain the following concepts. Everything in this Domain resolves around the “Product” being sold.

If you want to see some code related to this, please do checkout:

DDD Basic workshop Domain layer code

Let’s talk about some strategic patterns like bounded context, ubiquitous language and context map.

#eventsourcing #optimization #microservices