Why should you care?

Microservices should match business areas, not random technical splits. DDD gives you vocabulary to argue "Payment is its own context" with product managers, not just developers.

See it live — copy this example

Create a Web API project (dotnet new webapi), paste the code, then run dotnet run.

// Bounded context: Order — "Total" means sum of line items
public money Total => _lines.Sum(l => l.LineTotal);

// Bounded context: Shipping — "Total" might mean package weight tiers
// Different word, different service — do not share one "Total" table

Run Example »

This lesson uses terminal or setup steps. Run commands on your computer — the live editor appears on coding lessons.

What happened?

• Same English word can mean different things in different contexts.
• Separate services and models avoid one overloaded database table.

Try it yourself

1. Write a glossary: Order (ShopNest), Payment, Inventory — one sentence each.
2. Draw three boxes for Order, Payment, Inventory contexts.
3. Mark which nouns belong exclusively in each box.
4. Change a string or route in the example and save — watch Swagger or the RabbitMQ Management UI update.
5. Break the code on purpose (remove a semicolon), read the error message, then fix it.

Remember

Bounded context = boundary where a model makes sense. Microservice boundaries often follow DDD contexts. Use business words in class and method names.

Real-world: Banking transfer context

In banking, "Account" in customer app differs from "Ledger entry" in core banking. Separate services prevent one model from breaking both teams.

Outcome: Teams speak the same language in code and in Jira tickets.