Finding service boundaries with Domain-Driven Design — Microservices & System Design with .NET

2. Finding service boundaries with Domain-Driven Design

Intermediate★ Must knowLesson 2 of 9

Split by business capability, not by technical layer (never "a database service" + "a UI service").

DDD vocabulary interviewers use:

Term	Meaning	Example
Bounded context	A boundary in which a model and its language are consistent	"Customer" means different things in Sales and Support
Ubiquitous language	Shared terms between developers and business	Order, Shipment, Invoice
Aggregate	Cluster of objects changed together with one root enforcing rules	`Order` (root) + `OrderLines`
Domain event	Something that happened in the domain	`OrderPlaced`, `PaymentFailed`
Anti-corruption layer	Translator protecting your model from another system's model	Adapter over a legacy ERP

csharp

public class Order   // aggregate root: all changes go through it so rules are always enforced
{
    private readonly List<OrderLine> _lines = [];
    public IReadOnlyList<OrderLine> Lines => _lines;
    public OrderStatus Status { get; private set; } = OrderStatus.Draft;

    public void AddLine(int productId, int qty, decimal price)
    {
        if (Status != OrderStatus.Draft) throw new InvalidOperationException("Order already submitted");
        if (qty <= 0) throw new ArgumentOutOfRangeException(nameof(qty));
        _lines.Add(new OrderLine(productId, qty, price));
    }
}

Good boundary signals: high cohesion inside, few calls across, data owned by one place, a team can own it end to end.