Factory Pattern

A factory is one place that knows how to build an object. Callers ask for a finished thing and stay out of the details.

Two situations justify one. Construction is genuinely complex: several lookups, a generated identifier, a calculation, a set of child objects. Or the concrete type is not known until run time, and something has to choose it. Outside those two, a constructor is the factory, and it is already written.

public sealed class InvoiceFactory(
    IInvoiceNumbering numbering,
    ITaxRegionLookup taxRegions,
    IClock clock)
{
    public async Task<Invoice> FromOrderAsync(Order order, PaymentTerms terms, CancellationToken token)
    {
        TaxRegion region = await taxRegions.ForCountryAsync(order.ShippingCountry, token);
        string number = await numbering.NextAsync(clock.UtcNow.Year, token);
        DateTime dueUtc = terms.DueDateFrom(clock.UtcNow);

        var lines = order.Lines
            .Select(line => new InvoiceLine(
                line.Description,
                line.Quantity,
                line.UnitPrice,
                region.RateFor(line.ProductCategory)))
            .ToList();

        return new Invoice(order.CustomerId, number, dueUtc, lines);
    }
}

• Four things have to be settled before an invoice exists: the tax region for the destination, the next number in this year's sequence, the due date implied by the payment terms, and one invoice line per order line with the right rate applied.
• None of that belongs in the Invoice constructor. If it were there, the entity would need a numbering service and a tax lookup injected into it, which puts infrastructure dependencies inside the domain — the thing the previous module spent two lessons avoiding.
• It does not belong in the calling handler either, because then each of the three places that creates an invoice would repeat it, and the third one would use last year's sequence.
• The Invoice constructor stays a plain assignment plus its own invariant checks. Assembling the arguments is a separate job, and this is where it lives.

// Program.cs — the container registers each builder against a key
builder.Services.AddKeyedScoped<IPaymentRequestBuilder, CardRequestBuilder>("card");
builder.Services.AddKeyedScoped<IPaymentRequestBuilder, DirectDebitRequestBuilder>("direct-debit");
builder.Services.AddKeyedScoped<IPaymentRequestBuilder, BankTransferRequestBuilder>("bank-transfer");

// The factory is thin, because the container is doing the resolving
public sealed class PaymentRequestFactory(IServiceProvider services)
{
    public IPaymentRequestBuilder For(PaymentMethod method) =>
        services.GetKeyedService<IPaymentRequestBuilder>(method.Key)
            ?? throw new NotSupportedException($"No payment builder registered for {method.Key}.");
}

• The method a customer chose is data, arriving with the request, so the type cannot be selected at compile time. Something has to map a value to an implementation, and that mapping is what this factory is.
• Keyed registrations have been part of the built-in dependency injection container since .NET 8, so the lookup itself needs no code of yours.
• The throw matters. A payment method with no registered builder is a configuration mistake, and failing on the first request with a clear message beats returning null and producing a confusing error three frames away.
• An alternative with no container involvement: inject IEnumerable of the interface and index it by a property each implementation exposes, as the SOLID lesson did with discount policies. Choose on taste and on whether you mind the factory knowing about IServiceProvider.