Creational patterns aren't just for academic theory. In .NET, the Builder is how we configure apps, and the Factory is how we handle complex object creation.
Look at WebApplication.CreateBuilder(args). This is a master-class in the Builder pattern. It allows you to 'Chain' your configuration (Services, Middleware, Logging) in a logical, readable way. You should use this same pattern for your own complex domain objects.
When you have 5 different Payment Providers (Stripe, Paypal, etc.) and you don't know which one you need until runtime, you use a **PaymentFactory**.
public IPaymentProvider GetProvider(string type) => type switch { ... };Q: "Is the 'Factory' pattern still needed if we have DI?"
Architect Answer: "YES! DI handles 'Service' creation (what to use). The Factory handles 'Dynamic' creation (which one to use at runtime). If a user chooses 'Export to PDF' or 'Export to Excel', the DI container doesn't know which one to inject. You inject a Factory, and the Factory makes the decision based on user input. DI and Factory work together—they don't replace each other."