What does low coupling mean, what kinds of coupling exist in .NET systems, and how do you reduce the harmful ones?

1. Origins and vocabulary

2. Afferent and efferent coupling

A domain core should be stable (many depend on it, it depends on little). Adapters should be unstable (they depend on vendors and change often).

3. Connascence: a finer-grained lens

Rule: weaker connascence across boundaries, stronger only within a module.

4. Synchronous chains and availability

A → B → C, each 99.9% available
best-case availability of A's request ≈ 0.999 × 0.999 × 0.999 ≈ 99.7%
plus latency adds up, and a slow C ties up threads/connections in A and B

Events, caching and making non-critical calls asynchronous break the chain; timeouts and circuit breakers contain damage where synchronous calls remain.

5. Shared database → owned data, incrementally

1. Inventory every reader/writer and the columns used.
2. Pick an owner; route writes through the owner's API.
3. Publish events (outbox) for changes others care about.
4. Consumers build local read models; remove their direct reads.
5. Lock down permissions per schema.

Each step is independently deployable.

6. Coupling and cohesion together

High cohesion inside modules makes low coupling between them possible: when a feature's code and data live together, fewer calls and shared tables cross boundaries. Splitting a system along the wrong lines produces services that are both incohesive and tightly coupled ("distributed monolith").

7. Try it yourself

1. Visualise your project references (Visual Studio dependency diagram, NDepend or dotnet list reference).
2. Compute Ca/Ce for a few projects and check that high-Ca ones are stable and tested.
3. Replace one boolean control flag with two well-named methods.
4. Find positional tuples crossing module boundaries and replace them with records.
5. Map who reads and writes your most-shared table, and sketch an ownership plan.

// Control coupling: the caller dictates internal flow with flags.
public sealed class NotifierWithFlags
{
    public string Notify(string email, bool isRefund, bool skipEmail) =>
        skipEmail ? "skipped" : isRefund ? $"Refund email to {email}" : $"Receipt to {email}";
}

// Lower coupling: explicit operations and data coupling (only what is needed).
public sealed class Notifier
{
    public string SendReceipt(string email) => $"Receipt to {email}";
    public string SendRefundConfirmation(string email) => $"Refund email to {email}";
}

// Temporal decoupling: publish an event instead of calling other modules directly.
public sealed record OrderPlaced(Guid OrderId, string CustomerEmail, decimal Total);

public interface IEventPublisher
{
    Task PublishAsync<T>(T @event, CancellationToken ct = default);
}

public sealed class InMemoryPublisher : IEventPublisher
{
    public List<object> Published { get; } = [];
    public Task PublishAsync<T>(T @event, CancellationToken ct = default)
    {
        Published.Add(@event!);
        return Task.CompletedTask;
    }
}

public sealed class PlaceOrder(IEventPublisher events)
{
    // The order module does not know who sends emails, updates loyalty points or ships.
    public Task HandleAsync(Guid id, string email, decimal total, CancellationToken ct) =>
        events.PublishAsync(new OrderPlaced(id, email, total), ct);
}

public static class Demo
{
    public static async Task Main()
    {
        var publisher = new InMemoryPublisher();
        await new PlaceOrder(publisher).HandleAsync(Guid.NewGuid(), "[email protected]", 99m, default);
        Console.WriteLine(publisher.Published.Count);
        Console.WriteLine(new Notifier().SendReceipt("[email protected]"));
    }
}

In production, publish through a transactional outbox so the event is not lost if the broker is down.