Modular Architecture

A module is a slice of the application that owns a business capability end to end: its own entities, its own data, its own rules, and a small public contract that other modules use. Orders, Invoicing, Employees. Everything ships together as one application, in one process, behind one deployment.

This is the arrangement most teams should reach for, and it deserves saying plainly rather than as a compromise: get the boundaries right inside one deployable first. You get most of what separation buys — independent reasoning, contained changes, clear ownership — without network calls, distributed transactions or eight deployment pipelines. If a genuine need to split arrives later, the seams already exist and you split along a line you have been living with rather than one you guessed at.

// Invoicing module, public surface — the only types other modules may use
public interface IInvoicingApi
{
    Task<InvoiceSummary> CreateDraftForOrderAsync(NewInvoiceRequest request, CancellationToken token);
}

public sealed record NewInvoiceRequest(int OrderId, int CustomerId, IReadOnlyList<InvoiceLineDto> Lines);
public sealed record InvoiceSummary(int InvoiceId, string Number, decimal Total);

// Invoicing module, internals — not visible outside this project
internal sealed class InvoicingApi(InvoicingDbContext db, IInvoiceNumbering numbering) : IInvoicingApi
{
    public async Task<InvoiceSummary> CreateDraftForOrderAsync(
        NewInvoiceRequest request, CancellationToken token)
    {
        Invoice invoice = Invoice.DraftFor(request, await numbering.NextAsync(token));

        db.Invoices.Add(invoice);
        await db.SaveChangesAsync(token);

        return new InvoiceSummary(invoice.Id, invoice.Number, invoice.Total);
    }
}

// Invoicing module, registration — the host calls this and knows nothing else
public static class InvoicingModule
{
    public static IServiceCollection AddInvoicing(this IServiceCollection services, string connection)
    {
        services.AddDbContext<InvoicingDbContext>(options => options.UseSqlServer(connection));
        services.AddScoped<IInvoiceNumbering, SequentialNumbering>();
        services.AddScoped<IInvoicingApi, InvoicingApi>();
        return services;
    }
}

• The contract is three types: one interface and two records. Anything the Orders module needs from Invoicing goes through them, and the summary it gets back is a copy, not an entity it could modify.
• The implementation, the DbContext and the Invoice entity are internal. In C#, internal means visible inside the same assembly, so this containment is only enforced if each module is its own project. Inside a single project internal does nothing, and you are relying on discipline plus code review — which works until the week it does not.
• InvoicingDbContext maps only invoicing tables. Separate contexts over one database is a practical middle ground: one connection string, one transaction when you need it, but no module can quietly query another's tables because its context does not know they exist.
• AddInvoicing is the module's whole wiring story. Program.cs calls it and stays free of the module's internals, so removing the module later is one deleted line and one deleted project.

The seam is the point of all this. A module that only talks through a contract can become a separate service by replacing that contract's implementation with a network call, while every caller stays as it is. The boundary was already there; what changes is the transport.

That is why boundaries inside one application are worth the effort even if you never split. Most of the benefit people attribute to services comes from having drawn the lines, not from having deployed them separately.