Layered Architecture

A layer is a group of code with one kind of responsibility and a rule about what it is allowed to reference. The rule is the part that does the work. Without it you have named groups of files, which is filing, not architecture.

The four-layer arrangement below is the most common one in business applications. The names vary between teams — "service layer" for application, "data access layer" for infrastructure — so agree on your own vocabulary early and write it down.

Dependencies point inwards. Presentation depends on application, application depends on domain, and domain depends on nothing. Infrastructure also points inwards, which surprises people the first time: it sits at the outer edge but it depends on the layers inside it, because it implements interfaces that they define.

In .NET you can make this real rather than aspirational. One project per layer, and project references only in the permitted direction. The Domain project has no reference to Microsoft.EntityFrameworkCore. If someone writes a query in it, the build fails. That is the difference between a boundary and a folder.

// Web/Controllers/InvoicesController.cs
[HttpPost("{id:int}/approve")]
public async Task<IActionResult> Approve(int id)
{
    // Reaching straight past the application and domain layers.
    var invoice = await _db.Invoices
        .Include(i => i.Lines)
        .FirstOrDefaultAsync(i => i.Id == id);

    if (invoice is null) return NotFound();

    // A business rule, living in a controller.
    if (invoice.Status == InvoiceStatus.Paid)
        return BadRequest("Paid invoices cannot be approved again.");

    if (invoice.Lines.Sum(l => l.Amount) > 10_000m && !User.IsInRole("Finance"))
        return Forbid();

    invoice.Status = InvoiceStatus.Approved;
    invoice.ApprovedUtc = DateTime.UtcNow;
    await _db.SaveChangesAsync();

    return NoContent();
}

• The solution has four folders named after the four layers, so a diagram of it looks correct.
• This controller queries the database directly, which means the Web project references EF Core and the DbContext. The infrastructure boundary does not exist.
• Two business rules are in it: paid invoices cannot be re-approved, and large invoices need the Finance role. Neither can be tested without spinning up a web request, and neither is available to any other entry point — a background job approving invoices will have to repeat them, and the two copies will drift.
• Nothing here is broken today. It works, and for a small application it may be a reasonable choice. The point is that calling it layered is inaccurate, and the benefits people expect from layering are not present.

// Domain/Invoice.cs — no framework references in this project
public sealed class Invoice
{
    public InvoiceStatus Status { get; private set; }
    public DateTime? ApprovedUtc { get; private set; }
    private readonly List<InvoiceLine> _lines = [];

    public decimal Total => _lines.Sum(line => line.Amount);
    public bool NeedsFinanceApproval => Total > 10_000m;

    public void Approve(DateTime whenUtc)
    {
        if (Status is InvoiceStatus.Paid or InvoiceStatus.Approved)
            throw new InvoiceStateException("This invoice has already been approved.");

        Status = InvoiceStatus.Approved;
        ApprovedUtc = whenUtc;
    }
}

// Application/ApproveInvoiceHandler.cs
public sealed class ApproveInvoiceHandler(IInvoiceRepository invoices, IClock clock)
{
    public async Task<ApproveResult> HandleAsync(int invoiceId, bool callerIsFinance, CancellationToken token)
    {
        Invoice? invoice = await invoices.FindAsync(invoiceId, token);
        if (invoice is null) return ApproveResult.NotFound;
        if (invoice.NeedsFinanceApproval && !callerIsFinance) return ApproveResult.NotPermitted;

        invoice.Approve(clock.UtcNow);
        await invoices.SaveChangesAsync(token);
        return ApproveResult.Approved;
    }
}

• The rule about re-approval now lives on the entity that owns the state, so it holds no matter who calls it. The entity also refuses to be in an invalid state rather than trusting callers to check first.
• The threshold is expressed as a domain property, NeedsFinanceApproval. The application layer decides what to do about it; the domain decides what the number is.
• The handler returns a result value rather than an IActionResult, because it does not know it is being called over HTTP. The controller translates ApproveResult into a status code — that translation is the whole of its job.
• IClock is an interface over the current time. Injecting it keeps the domain deterministic in tests, which is worth the small ceremony anywhere a date affects a rule.