Loading...
System Design and AI Engineering, by Roni Das. 974 interactive lessons.
Start LearningIntermediate · Microservices Architecture
A way of designing software around the business domain: the code uses the same words as the business, and the system is split into bounded contexts, each with its own model.
In short
Domain-driven design (DDD) is a way of building software where the structure and words of the code follow the business it serves. The system is split into bounded contexts, each with its own model and its own vocabulary, shared with the business experts.
In short
Domain-driven design (DDD) is a way of building software where the structure and words of the code follow the business it serves. The system is split into bounded contexts, each with its own model and its own vocabulary, shared with the business experts.
This page is the free part.
₹499 in India$49 everywhere elseonce, for the whole course
The System Design course covers Domain-Driven Design across a run of lessons, not one page. These 4 alone are about 95 minutes of step-by-step reading, every one with a quiz.
Domain-driven design shapes software around the business, not the database. Covers bounded contexts, the building blocks, and DDD with microservices.
Group related domain objects into a single unit with one entry point, the consistency boundary of your domain.
Draw clear boundaries around domain models, where 'Customer' means one thing inside and something different outside.
Keep the business running during disruptions, beyond IT into organizational resilience.
all part of
System Design Masterclass
770 lessons · about 283 hours · 18 free to read
₹499in India, by UPI
$49everywhere else, by PayPal
Ive started this course by accident - LLM advised me this site. When I passed few free lessons, I had no doubt - this course should be bought. And I did it with special pleasent price and it was best decision of the month. Content is great, interesting to read and with a lot of practial cases (what makes it different from other souces and books) I hope to teach all the lessons, that will be my supergoal. Glad that I found this resource and speacial Thank You to Roni Das - Great Job!
You own this course
Continue with Domain-Driven Design (DDD)pay once,
yours for life
Domain-driven design, or DDD, is an approach to building software. Eric Evans named it in his 2003 book, Domain-Driven Design. A domain is the business area your software serves, such as banking, insurance or shipping. DDD says the code should be built around a model of that domain: its processes, its rules and its words.
The lesson starts with a bank that did the opposite. Developers built a loan system around tables: loans, customers, payments, transactions. Then the business asked for underwriting, the process of deciding whether to lend. Then risk scoring. Then loan restructuring. Each request added columns to the loans table. After two years it had 87 columns, and changing anything meant understanding all of them.
The problem was not the database. The team had modelled data, not the business. In a bank, underwriting, servicing and collections are separate processes. They have separate rules, separate teams and separate words. DDD says the software should have separate models for them too. The shape of the code should match the shape of the business.
DDD has two levels. Strategic design is the big picture: how you divide the domain. The lesson says this is where most teams should start. Its main ideas are these:
Drawn from the lesson Domain-Driven Design (DDD).
The bounded context is the idea people find hardest, so the lesson shows it with one word. Lending sees a Customer as an applicant with a credit score. Servicing sees a borrower with a payment history. Collections sees a debtor with delinquency records, meaning missed payments. Same word, three meanings. Martin Fowler gives the same kind of example from a utility company, where "meter" meant different things to different departments.
DDD does not try to force one model on the whole company. Evans accepted that one unified model for a large system is not practical. So each context keeps its own model, and the contexts talk through clear connections. In the lesson's design they talk through domain events on Kafka, a message broker. A domain event is a record that something happened which others care about, such as LoanApproved or PaymentMissed.
The lesson calls the ubiquitous language the most important and most underrated idea in DDD. Fowler describes it as a common, rigorous language between developers and users.
Here is the lesson's insurance example. The business says the policyholder wants to exercise their rider. A rider is an add-on to an insurance policy. A developer who does not know the word writes User.activateFeature(featureId). When the business reads that code, they say a rider is not a feature. With a shared language, the developer writes Policyholder.exerciseRider(riderId). Now the code reads like the business conversation, and a domain expert can check it.
This is not cosmetic. When code uses the business's words, a misunderstanding shows up at once. When code uses generic words like user, item or process, translation errors hide for months and come back as bugs. The lesson's rule: if a term exists in the business, it exists in the code with exactly the same meaning.
Tactical design is the code level: how you build the model inside one bounded context. The lesson lists six building blocks:
The lesson warns about one common mistake. Teams put all the logic in domain services and leave entities as empty bags of data. This is called the anemic domain model, and it loses most of what DDD offers.
DDD code is usually split into four layers. The interface layer handles HTTP. The application layer runs use cases. The domain layer holds the business rules and depends on nothing outside itself. The infrastructure layer handles the database and messaging. Dependencies point inward, so the domain layer never imports from the others.
The lesson calls DDD and microservices natural partners, because DDD gives you the boundaries that microservices need. Its mapping is simple. A bounded context becomes a service with its own database, which is the database per service pattern. The ubiquitous language becomes the service's API. Domain events become asynchronous messages between services. Aggregates become the edges of each local transaction.
Without DDD, the lesson says, splitting a system is guesswork. Teams split by technical layer, such as a UI service and a data service, or by entity, such as a User service and an Order service. They end up with services that are so tightly coupled that none can be deployed alone.
With DDD, boundaries come from the business. You find where teams use different words, and those lines become service lines. A service boundary that matches a business boundary stays stable. Events between contexts also open the door to event sourcing and CQRS, though neither is required.
DDD is expensive. It needs steady work between developers and domain experts, modelling workshops and a willingness to refactor when the model is wrong. The lesson says your first model will be wrong, and the value is in improving it as you learn.
DDD is too much for simple domains. A to-do list app does not need bounded contexts and aggregates. DDD pays off where the rules are intricate: insurance, banking, healthcare, logistics.
The lesson's practical path has four steps. Start with strategic DDD, meaning bounded contexts and a shared language, even if you skip the tactical patterns. Use Event Storming, a sticky-note workshop invented by Alberto Brandolini, to find the boundaries. Use entities, value objects and aggregates only in the complex subdomains. Keep simple, generic parts simple, because plain create, read, update and delete code is fine where it is enough.
Next, read the Domain-Driven Design (DDD) lesson for the layered architecture and the building-block diagrams. Then the Bounded Context lesson goes deeper on drawing the lines.
Eric Evans, Domain-Driven Design (2003)
The book that named the approach and its building blocks: entities, value objects, aggregates, repositories and bounded contexts.
Event Storming
A workshop format created by Alberto Brandolini to discover domain events and context boundaries with domain experts and developers in one room.
DDD, domain-driven design, is about how you model and structure the software around the business. BDD, behavior-driven development, is a way of writing tests and specifications as examples of behavior, often in a given, when, then form. Dan North introduced BDD. They work well together: BDD scenarios can be written in DDD's ubiquitous language.
DDD decides what the model and its boundaries should be. TDD, test-driven development, is a coding habit: write a failing test, write code until it passes, then clean up. One is about design, the other about how you write each piece of code. Many teams use TDD to build the domain model that DDD describes.
It is good for complex domains with intricate business rules, such as banking, insurance or logistics, where a shared language and clear boundaries prevent costly misunderstandings. It is a poor fit for simple apps, where its modelling work adds ceremony and little value. Many teams adopt only the strategic part, bounded contexts and ubiquitous language, and skip the tactical patterns.
Eric Evans's 2003 book is the original source and is still the reference for the ideas. It is long and dense, and many readers find the strategic design chapters near the end the most useful. Evans's free Domain-Driven Design Reference gives short definitions of each pattern and is a good companion.
It is a boundary inside which one model and one set of word meanings apply. In the lesson's bank, Customer means an applicant in Lending, a borrower in Servicing and a debtor in Collections. Each of those is a separate bounded context.
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
Database per Service
A microservices pattern where each service owns its private database. No other service can access it directly. Enforces loose coupling but complicates cross-service queries.
Event Sourcing
Storing every state change as an immutable event instead of just the current state. You can rebuild any past state by replaying events.
CQRS
Command Query Responsibility Segregation: using different models for reading and writing data. Reads and writes have different performance needs, so separate them.
Monolith
A single, unified application where all features share the same codebase and deployment. Simpler to start with but harder to scale individual parts.
Service Discovery
The mechanism by which microservices find and communicate with each other. Services register themselves and others can look them up by name.
This page explains the idea. The "Domain-Driven Design (DDD)" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Domain-Driven Design (DDD) lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.