Separation of Concerns

A concern is a reason the code might have to change. Separation of concerns means arranging things so that each part answers to one of those reasons.

That phrasing matters. "One thing" is too vague to act on — whether a method does one thing depends entirely on how you squint at it. "One reason to change" is a question you can answer by looking at your own change history. If the VAT rate changes, which files do you open? If you move email providers, which files do you open? If the answer is the same file both times, that file has two concerns in it.

public async Task<int> PlaceOrderAsync(OrderRequest request)
{
    if (request.Lines.Count == 0)
        throw new ArgumentException("An order needs at least one line.");

    decimal net = request.Lines.Sum(line => line.UnitPrice * line.Quantity);
    decimal vat = Math.Round(net * 0.20m, 2);
    decimal total = net + vat;

    var order = new Order
    {
        CustomerId = request.CustomerId,
        Total = total,
        PlacedUtc = DateTime.UtcNow,
    };

    _db.Orders.Add(order);
    await _db.SaveChangesAsync();

    await _http.PostAsJsonAsync(
        "https://email.internal.example/send",
        new { to = request.CustomerEmail, subject = "Order received", body = $"Total {total:C}." });

    return order.Id;
}

• Lines 3-4 are a validation rule. They change when the rules about what makes an acceptable order change.
• Lines 6-8 are a pricing calculation. They change when tax rates change, or when discounts arrive, or when rounding has to follow a different convention.
• Lines 10-19 are persistence. They change when the storage technology or the table shape changes.
• Lines 21-24 are notification. They change when the email provider changes, or when someone decides the customer should get a text message instead.
• Four independent reasons, one method. Any of them being touched puts the other three at risk, and none of them can be tested without the other three being present.

The cost is not aesthetic. Testing the VAT calculation requires a database and an HTTP endpoint, because the calculation is welded to both. Changing the email provider means editing a method that also decides whether an order is valid. And a reader who wants to know the pricing rule has to read twenty-four lines of unrelated machinery to find three lines of arithmetic.

Separating the concerns means each of those four reasons lives somewhere of its own, and the original method becomes a short description of the sequence.

public sealed class PlaceOrderHandler(
    IOrderValidator validator,
    IOrderPricing pricing,
    IOrderRepository orders,
    ICustomerNotifier notifier)
{
    public async Task<int> HandleAsync(OrderRequest request, CancellationToken token)
    {
        validator.Validate(request);

        OrderTotals totals = pricing.Price(request.Lines);
        Order order = Order.Create(request.CustomerId, request.Lines, totals);

        await orders.AddAsync(order, token);
        await notifier.OrderReceivedAsync(order, token);

        return order.Id;
    }
}

• The parameters on the class declaration are a primary constructor — a C# 12 shorthand that declares the constructor and makes its parameters usable throughout the class body, without writing matching fields.
• The handler now states the sequence and nothing else: validate, price, create, store, notify. Read it once and you know what placing an order involves.
• Each collaborator has one reason to change. A VAT change touches the pricing implementation. A provider change touches the notifier implementation. Neither touches this file.
• Pricing can now be tested by calling it with a list of lines. No database, no HTTP, no setup — a few milliseconds per test.