Why should you care?

Without rules, you get a "distributed monolith" — many repos but still tangled databases and synchronous chains. Principles stop that mess early.

See it live — copy this example

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

// ✅ Good boundary — Order service owns Order aggregate
public class Order
{
    public Guid Id { get; private set; }
    public int CustomerId { get; private set; }
    public OrderStatus Status { get; private set; }
    public void MarkPaid() => Status = OrderStatus.Paid;
}

// ❌ Bad — Order service updates Payment table directly
// await _paymentDb.Transactions.AddAsync(...); // wrong service!

Run Example »

Edit the code and click Run — like W3Schools Try it Yourself.

What happened?

• Order owns order state.
• Payment service owns transactions.
• They integrate via API or events — not by reaching into each other database.

Try it yourself

1. Pick ShopNest Order — list five things it owns (order id, lines, status, customer id, created date).
2. List five things it does NOT own (card number, SMS template, warehouse bin location).
3. Add one domain class Order with a method MarkPaid().
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

Align services with business capabilities (order, pay, notify). Database per service — integrate via API or events. Assume the network fails — plan retries and timeouts later.

Real-world: Flipkart payment isolation

Payment PCI rules require stricter security and audits. A separate Payment service with its own DB lets security scope stay small.

Outcome: Compliance and deploy boundaries match business risk — not arbitrary folder names.