Create an interface.
Create an implementation.
Register both with the DI container.
Inject the interface into the controller or service.<\/p>\n\n\n\n
For example: Then: This is a perfectly reasonable pattern.<\/p>\n\n\n\n The problem starts when we assume that every dependency in an ASP.NET Core application needs an interface<\/strong>.<\/p>\n\n\n\n We end up with interfaces that have one implementation, services that simply forward calls to another service, unnecessary layers, and a dependency graph that is harder to understand than the business problem it is supposed to solve.<\/p>\n\n\n\n The real purpose of an abstraction is not to make dependency injection possible.<\/p>\n\n\n\n The purpose of an abstraction is to create a useful boundary around something that may need to change independently.<\/strong><\/p>\n\n\n\n ASP.NET Core has built-in dependency injection, which allows us to register concrete classes directly: We can then inject the concrete type: There is nothing inherently wrong with this.<\/p>\n\n\n\n We don’t need: simply because ASP.NET Core has a dependency injection container.<\/p>\n\n\n\n An interface becomes valuable when it represents a boundary that we actually care about.<\/p>\n\n\n\n For example: Here, the abstraction makes sense because the application shouldn’t need to know that the payment implementation happens to use a particular provider.<\/p>\n\n\n\n The controller or application service depends on: rather than: That is a meaningful dependency boundary.<\/p>\n\n\n\n A common ASP.NET Core pattern looks like this: And then: This may be completely appropriate.<\/p>\n\n\n\n But suppose Then we should ask:<\/p>\n\n\n\n Why does If the answer is:<\/p>\n\n\n\n “Because we use dependency injection.”<\/p>\n<\/blockquote>\n\n\n\n that’s not a particularly strong reason.<\/p>\n\n\n\n We could simply write: and: The application is still using dependency injection.<\/p>\n\n\n\n We’ve simply avoided an abstraction that doesn’t currently provide meaningful value.<\/p>\n\n\n\n ASP.NET Core applications frequently interact with infrastructure and external systems.<\/p>\n\n\n\n These are strong candidates for abstraction.<\/p>\n\n\n\n Examples include:<\/p>\n\n\n\n Consider an application that sends emails.<\/p>\n\n\n\n Instead of allowing application code to depend directly on a specific email provider: we can introduce a business-oriented abstraction: The infrastructure implementation can depend on the external provider: And register it: Now the rest of the application depends on: rather than the provider’s SDK.<\/p>\n\n\n\n If the email provider changes later, the change is largely isolated to the infrastructure implementation.<\/p>\n\n\n\n This is the kind of future-proofing that is worth paying for.<\/p>\n\n\n\n Another common mistake is wrapping framework functionality without a clear reason.<\/p>\n\n\n\n For example, developers sometimes create abstractions such as: or wrappers around framework services simply because they believe every dependency should be hidden.<\/p>\n\n\n\n But ASP.NET Core already provides well-defined abstractions.<\/p>\n\n\n\n For example: These are already abstractions.<\/p>\n\n\n\n We generally don’t need to create: unless our application has a specific domain reason for doing so.<\/p>\n\n\n\n Wrapping a framework abstraction with another abstraction can simply add another layer without protecting us from anything meaningful.<\/p>\n\n\n\n Imagine an ASP.NET Core application containing: And every interface has exactly one implementation.<\/p>\n\n\n\n This isn’t automatically bad.<\/p>\n\n\n\n But it is worth questioning.<\/p>\n\n\n\n If every class is abstracted, developers now have to navigate between interfaces and implementations constantly.<\/p>\n\n\n\n For example: A simple request may now cross five architectural boundaries.<\/p>\n\n\n\n The important question becomes:<\/p>\n\n\n\n Does each boundary represent something meaningful?<\/p>\n<\/blockquote>\n\n\n\n If not, we may have created architecture for the sake of architecture.<\/p>\n\n\n\n One useful abstraction boundary in ASP.NET Core is the boundary between the HTTP layer and application logic.<\/p>\n\n\n\n A controller should generally not contain complicated business logic.<\/p>\n\n\n\n Instead of: we can delegate the application behavior: Whether The important abstraction here is not necessarily: The important boundary is: That distinction matters.<\/p>\n\n\n\n We shouldn’t confuse architectural boundaries<\/strong> with interfaces<\/strong>.<\/p>\n\n\n\n An abstraction can be useful without necessarily requiring an interface, and an interface can exist without representing a useful architectural boundary.<\/p>\n\n\n\n Your DI registrations are effectively a map of your application’s architecture.<\/p>\n\n\n\n For example: These registrations tell us something meaningful:<\/p>\n\n\n\n Compare that with: If all of these interfaces simply exist because “that’s our standard pattern,”<\/em> the DI configuration isn’t communicating much about the architecture.<\/p>\n\n\n\n It’s just registering layers.<\/p>\n\n\n\n Good dependency injection configuration should help us understand the system.<\/p>\n\n\n\n A useful way to think about dependency injection is:<\/p>\n\n\n\n Abstract things that are likely to vary.<\/strong><\/p>\n<\/blockquote>\n\n\n\n Suppose your application uses a payment provider. The payment provider is outside your control.<\/p>\n\n\n\n It may change.<\/p>\n\n\n\n Therefore, an abstraction is valuable.<\/p>\n\n\n\n Now consider a simple domain calculation: There may be no reason to create: unless there is an actual reason for multiple implementations or another meaningful boundary.<\/p>\n\n\n\n This gives us a useful principle:<\/p>\n\n\n\n Put abstractions around volatility, not around everything.<\/strong><\/p>\n<\/blockquote>\n\n\n\n ASP.NET Core provides We can register a typed client: Then: We don’t necessarily need to introduce multiple abstractions around this.<\/p>\n\n\n\n But if the rest of the application shouldn’t know anything about HTTP or the external payment API, we might introduce: The implementation can then use the typed HTTP client. Now each boundary has a reason.<\/p>\n\n\n\n The application understands payments.<\/p>\n\n\n\n The infrastructure understands HTTP.<\/p>\n\n\n\n The external API remains an implementation detail.<\/p>\n\n\n\n One of the most common arguments for interfaces is:<\/p>\n\n\n\n “We need an interface so we can mock it.”<\/p>\n<\/blockquote>\n\n\n\n For example: The interface exists primarily so a test can create: Testing considerations are important, but this shouldn’t automatically determine the architecture.<\/p>\n\n\n\n If the interface doesn’t represent a meaningful boundary, we may be creating production complexity to make a particular testing technique easier.<\/p>\n\n\n\n A better question is:<\/p>\n\n\n\n What should actually be isolated in this test?<\/p>\n<\/blockquote>\n\n\n\n External systems are excellent candidates.<\/p>\n\n\n\n For example: A checkout test can replace the external payment dependency with a test double.<\/p>\n\n\n\n That is valuable because payment processing is an external boundary.<\/p>\n\n\n\n By contrast, creating interfaces for every internal class simply to mock every interaction can lead to tests that describe implementation structure rather than business behavior.<\/p>\n\n\n\n ASP.NET Core’s options pattern provides another example of a useful abstraction.<\/p>\n\n\n\n Instead of injecting we can model configuration explicitly: Register it: Then consume it: This is a useful abstraction because the application is expressing a meaningful configuration concept: rather than spreading configuration keys throughout the codebase.<\/p>\n\n\n\n There are situations where an abstraction can protect application code from infrastructure or framework-specific details.<\/p>\n\n\n\n For example, suppose your application needs the current time.<\/p>\n\n\n\n You could write: throughout the application.<\/p>\n\n\n\n But if business logic needs deterministic time during testing or a consistent time source, an abstraction may be useful.<\/p>\n\n\n\n Modern .NET also provides the You can inject it: Register: This is a good example of using an abstraction because the dependency represents something that can vary in a meaningful way, especially during testing.<\/p>\n\n\n\n There is no need to invent: when the framework already gives us an appropriate abstraction.<\/p>\n\n\n\n Consider this: Someone might say:<\/p>\n\n\n\n “We may eventually get customers from another system.”<\/p>\n<\/blockquote>\n\n\n\n That’s possible.<\/p>\n\n\n\n But what does the alternative system look like?<\/p>\n\n\n\n A database?<\/p>\n\n\n\n A CRM?<\/p>\n\n\n\n A remote API?<\/p>\n\n\n\n A cache?<\/p>\n\n\n\n An event stream?<\/p>\n\n\n\n We don’t know.<\/p>\n\n\n\n If we don’t know what the variation actually looks like, we may not know what the correct abstraction should be.<\/p>\n\n\n\n This is one of the biggest problems with speculative abstraction.<\/p>\n\n\n\n We can easily create an abstraction today that prevents us from designing the right abstraction tomorrow.<\/p>\n\n\n\n Sometimes the best decision is to wait.<\/p>\n\n\n\n Developers sometimes fear removing an abstraction because they believe that once an interface exists, it must remain forever.<\/p>\n\n\n\n It doesn’t.<\/p>\n\n\n\n Suppose we start with: Later we discover that there are two implementations: At that point we can introduce: and update the DI registration: The important thing is that we introduced the abstraction when we understood the problem.<\/p>\n\n\n\n This is often preferable to maintaining an unnecessary interface for years because we were afraid that we might eventually need it.<\/p>\n\n\n\n Before adding an interface to an ASP.NET Core application, ask:<\/p>\n\n\n\n If it represents an external system, infrastructure dependency, or important business concept, that’s a strong signal.<\/p>\n\n\n\n If a third-party provider can change without the business logic changing, abstraction is often valuable.<\/p>\n\n\n\n If replacing the dependency would require changes throughout the application, isolate it now.<\/p>\n\n\n\n Two implementations are stronger evidence than one hypothetical implementation.<\/p>\n\n\n\n Before creating your own interface, check whether the framework already provides an appropriate abstraction such as: If adding an interface makes the architecture harder to understand without protecting anything meaningful, reconsider it.<\/p>\n\n\n\n A pragmatic ASP.NET Core application might look like this: Notice that not everything is an interface.<\/p>\n\n\n\n The interfaces exist where they provide valuable boundaries.<\/p>\n\n\n\n This keeps the dependency graph relatively simple while still protecting the application from important external changes.<\/p>\n\n\n\n It is tempting to think that good architecture means maximum flexibility.<\/p>\n\n\n\n But maximum flexibility often means maximum complexity.<\/p>\n\n\n\n An application that supports ten hypothetical implementations of every component isn’t necessarily better designed than an application that supports the one implementation it actually needs.<\/p>\n\n\n\n The goal should be appropriate flexibility<\/strong>.<\/p>\n\n\n\n We want to make important changes easier without making ordinary development unnecessarily difficult.<\/p>\n\n\n\n In an ASP.NET Core application, that often means: Dependency injection makes it easy to introduce abstractions in ASP.NET Core.<\/p>\n\n\n\n That convenience can be both a strength and a weakness.<\/p>\n\n\n\n It is easy to fall into a pattern where every service gets an interface, every interface gets an implementation, and every implementation gets registered with the DI container.<\/p>\n\n\n\n But dependency injection is a mechanism\u2014not an architectural goal.<\/p>\n\n\n\n The more important question is:<\/p>\n\n\n\n What are we protecting ourselves from?<\/strong><\/p>\n<\/blockquote>\n\n\n\n If an application depends on a payment provider, email service, external API, message broker, or other infrastructure that may change independently, an abstraction can be extremely valuable.<\/p>\n\n\n\n If a class is simple, internal, stable, and has one obvious implementation, a concrete dependency may be the better design.<\/p>\n\n\n\n The best ASP.NET Core applications aren’t necessarily the ones with the most interfaces.<\/p>\n\n\n\n They’re the ones where the interfaces that do<\/em> exist have a clear reason for being there.<\/p>\n\n\n\n Don’t abstract because you can. Abstract because the boundary matters.<\/strong><\/p>\n\n\n\n That is how dependency injection becomes an architectural tool rather than just a registration mechanism.<\/p>\n","protected":false},"excerpt":{"rendered":" ASP.NET Core makes dependency injection so easy that creating abstractions can sometimes become automatic. Create an interface.Create an implementation.Register both with the DI container.Inject the interface into the controller or service. For example:builder.Services.AddScoped<IOrderService, OrderService>(); Then:public class OrdersController : ControllerBase { private readonly IOrderService _orderService; public OrdersController(IOrderService orderService) { _orderService = orderService; } } This is… Read More »Creating abstractions to avoid possible future problems in ASP.NET Core<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/posts\/41"}],"collection":[{"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/comments?post=41"}],"version-history":[{"count":2,"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/posts\/41\/revisions"}],"predecessor-version":[{"id":63,"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/posts\/41\/revisions\/63"}],"wp:attachment":[{"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/media?parent=41"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/categories?post=41"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/twobitranch.io\/index.php\/wp-json\/wp\/v2\/tags?post=41"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}builder.Services.AddScoped<IOrderService, OrderService>();<\/code><\/p>\n\n\n\npublic class OrdersController : ControllerBase { private readonly IOrderService _orderService; public OrdersController(IOrderService orderService) { _orderService = orderService; } }<\/code><\/p>\n\n\n\n
\n\n\n\nDependency Injection Is Not the Same as Abstraction<\/h3>\n\n\n\n
builder.Services.AddScoped<OrderService>();<\/code><\/p>\n\n\n\npublic class OrdersController : ControllerBase { private readonly OrderService _orderService; public OrdersController(OrderService orderService) { _orderService = orderService; } }<\/code><\/p>\n\n\n\nIOrderService<\/code><\/p>\n\n\n\nbuilder.Services.AddScoped<IPaymentGateway, StripePaymentGateway>();<\/code><\/p>\n\n\n\nIPaymentGateway<\/code><\/p>\n\n\n\nStripePaymentGateway<\/code><\/p>\n\n\n\n
\n\n\n\nDon’t Create Interfaces Automatically<\/h3>\n\n\n\n
public interface IProductService { Task<Product?> GetAsync(int id); } <\/code>public class ProductService : IProductService { public async Task<Product?> GetAsync(int id) { \/\/ Implementation } }<\/code><\/p>\n\n\n\nbuilder.Services.AddScoped<IProductService, ProductService>();<\/code><\/p>\n\n\n\nProductService<\/code> is an internal application service with one implementation and no meaningful alternative implementation.<\/p>\n\n\n\n\n
IProductService<\/code> exist?<\/p>\n<\/blockquote>\n\n\n\n\n
builder.Services.AddScoped<ProductService>();<\/code><\/p>\n\n\n\npublic class ProductsController : ControllerBase { private readonly ProductService _productService; public ProductsController(ProductService productService) { _productService = productService; } }<\/code><\/p>\n\n\n\n
\n\n\n\nWhere Abstractions Are Particularly Useful in ASP.NET Core<\/h3>\n\n\n\n
\n
public class OrderService { private readonly SendGridClient _client; public OrderService(SendGridClient client) { _client = client; } }<\/code><\/p>\n\n\n\npublic interface IEmailSender { Task SendAsync( string recipient, string subject, string body); }<\/code><\/p>\n\n\n\npublic class EmailSender : IEmailSender { private readonly SendGridClient _client; public EmailSender(SendGridClient client) { _client = client; } public async Task SendAsync( string recipient, string subject, string body) { \/\/ Send using the provider } }<\/code><\/p>\n\n\n\nbuilder.Services.AddScoped<IEmailSender, EmailSender>();<\/code><\/p>\n\n\n\nIEmailSender<\/code><\/p>\n\n\n\n
\n\n\n\nDon’t Abstract ASP.NET Core Itself<\/h3>\n\n\n\n
public interface IControllerBase { }<\/code><\/p>\n\n\n\nILogger<T> IConfiguration IHttpClientFactory IHostEnvironment IOptions<T><\/code><\/p>\n\n\n\nIMyLogger IMyConfiguration IMyHttpClientFactory<\/code><\/p>\n\n\n\n
\n\n\n\nAvoid the “Interface for Every Service” Rule<\/h3>\n\n\n\n
IUserService UserService IOrderService OrderService IProductService ProductService ICustomerService CustomerService IAddressService AddressService IReportService ReportService<\/code><\/p>\n\n\n\nOrdersController \u2193 IOrderService \u2193 OrderService \u2193 IOrderRepository \u2193 OrderRepository \u2193 ApplicationDbContext<\/code><\/p>\n\n\n\n\n
\n\n\n\nControllers Should Depend on Application Behavior<\/h3>\n\n\n\n
[HttpPost] public async Task<IActionResult> Create(CreateOrderRequest request) { \/\/ Validate everything \/\/ Calculate totals \/\/ Apply discounts \/\/ Save order \/\/ Send email \/\/ Publish event return Ok(); }<\/code><\/p>\n\n\n\n[HttpPost] public async Task<IActionResult> Create(CreateOrderRequest request) { var order = await _orderService.CreateAsync(request); return Ok(order); }<\/code><\/p>\n\n\n\n_orderService<\/code> is represented by an interface depends on the application.<\/p>\n\n\n\nIOrderService<\/code><\/p>\n\n\n\nHTTP concerns \u2193 Application behavior<\/code><\/p>\n\n\n\n
\n\n\n\nDependency Injection Should Describe Your Architecture<\/h3>\n\n\n\n
builder.Services.AddScoped<OrderService>(); builder.Services.AddScoped<IEmailSender, EmailSender>(); builder.Services.AddScoped<IPaymentGateway, StripePaymentGateway>();<\/code><\/p>\n\n\n\n\n
OrderService<\/code> is an application service.<\/li>\n\n\n\nIEmailSender<\/code> represents an infrastructure boundary.<\/li>\n\n\n\nIPaymentGateway<\/code> represents a replaceable external dependency.<\/li>\n<\/ul>\n\n\n\nbuilder.Services.AddScoped<IOrderService, OrderService>(); builder.Services.AddScoped<IProductService, ProductService>(); builder.Services.AddScoped<ICustomerService, CustomerService>(); builder.Services.AddScoped<IAddressService, AddressService>(); builder.Services.AddScoped<IReportService, ReportService>();<\/code><\/p>\n\n\n\n
\n\n\n\nUse Abstractions at the Point of Instability<\/h3>\n\n\n\n
\n
CheckoutService | v IPaymentGateway | v StripePaymentGateway<\/code><\/p>\n\n\n\npublic class OrderTotalCalculator { public decimal Calculate(Order order) { return order.Items.Sum(x => x.Price); } }<\/code><\/p>\n\n\n\npublic interface IOrderTotalCalculator { decimal Calculate(Order order); }<\/code><\/p>\n\n\n\n\n
\n\n\n\nHttpClient Is a Good Example of a Boundary<\/h3>\n\n\n\n
IHttpClientFactory<\/code>, which already solves many concerns associated with managing HttpClient<\/code>.<\/p>\n\n\n\nbuilder.Services.AddHttpClient<PaymentClient>(client => { client.BaseAddress = new Uri(\"https:\/\/payments.example.com\"); });<\/code><\/p>\n\n\n\npublic class PaymentClient { private readonly HttpClient _httpClient; public PaymentClient(HttpClient httpClient) { _httpClient = httpClient; } public async Task<PaymentResponse> ChargeAsync( PaymentRequest request) { \/\/ HTTP communication } }<\/code><\/p>\n\n\n\npublic interface IPaymentGateway { Task<PaymentResult> ChargeAsync( decimal amount, string customerId); }<\/code><\/p>\n\n\n\nApplication | v IPaymentGateway | v PaymentGateway | v PaymentClient | v External API<\/code><\/p>\n\n\n\n
\n\n\n\nDon’t Use Interfaces Just for Unit Testing<\/h3>\n\n\n\n
\n
public interface IProductService { Task<Product?> GetAsync(int id); }<\/code><\/p>\n\n\n\nvar mock = new Mock<IProductService>();<\/code><\/p>\n\n\n\n\n
public interface IPaymentGateway { Task<PaymentResult> ChargeAsync(...); }<\/code><\/p>\n\n\n\n
\n\n\n\nConfiguration Is Another Important Abstraction<\/h3>\n\n\n\n
IConfiguration<\/code> everywhere:public class PaymentService { private readonly IConfiguration _configuration; public PaymentService(IConfiguration configuration) { _configuration = configuration; } }<\/code><\/p>\n\n\n\npublic class PaymentOptions { public string ApiKey { get; set; } = string.Empty; public string BaseUrl { get; set; } = string.Empty; }<\/code><\/p>\n\n\n\nbuilder.Services.Configure<PaymentOptions>( builder.Configuration.GetSection(\"Payment\"));<\/code><\/p>\n\n\n\npublic class PaymentGateway { private readonly PaymentOptions _options; public PaymentGateway( IOptions<PaymentOptions> options) { _options = options.Value; } }<\/code><\/p>\n\n\n\nPaymentOptions<\/code><\/p>\n\n\n\n
\n\n\n\nAbstractions Can Protect You From Framework Changes Too<\/h3>\n\n\n\n
var now = DateTime.UtcNow;<\/code><\/p>\n\n\n\nTimeProvider<\/code> abstraction.<\/p>\n\n\n\npublic class SubscriptionService { private readonly TimeProvider _timeProvider; public SubscriptionService(TimeProvider timeProvider) { _timeProvider = timeProvider; } public bool HasExpired(DateTimeOffset expiresAt) { return _timeProvider.GetUtcNow() >= expiresAt; } }<\/code><\/p>\n\n\n\nbuilder.Services.AddSingleton(TimeProvider.System);<\/code><\/p>\n\n\n\nIMyTimeProvider<\/code><\/p>\n\n\n\n
\n\n\n\nDon’t Create an Abstraction for a Future You Cannot Describe<\/h3>\n\n\n\n
public interface ICustomerProvider { Task<Customer> GetCustomerAsync(Guid id); }<\/code><\/p>\n\n\n\n\n
\n\n\n\nRefactoring an Abstraction Later Is Often Cheaper Than Maintaining a Bad One<\/h3>\n\n\n\n
public class CustomerService { }<\/code><\/p>\n\n\n\nDatabaseCustomerService CrmCustomerService<\/code><\/p>\n\n\n\npublic interface ICustomerService { }<\/code><\/p>\n\n\n\nbuilder.Services.AddScoped<ICustomerService, DatabaseCustomerService>();<\/code><\/p>\n\n\n\n
\n\n\n\nA Practical Decision Framework<\/h3>\n\n\n\n
Does this represent a meaningful boundary?<\/h3>\n\n\n\n
Is the dependency likely to change independently?<\/h3>\n\n\n\n
Would changing it later be expensive?<\/h3>\n\n\n\n
Is there already meaningful variation?<\/h3>\n\n\n\n
Does ASP.NET Core already provide the abstraction?<\/h3>\n\n\n\n
ILogger<T> IHttpClientFactory IOptions<T> TimeProvider IHostEnvironment<\/code><\/p>\n\n\n\nDoes the abstraction make the code easier to understand?<\/h3>\n\n\n\n
\n\n\n\nA Simple ASP.NET Core Architecture<\/h3>\n\n\n\n
ASP.NET Core | Controller | v OrderService | +----------+----------+ | | v v IPaymentGateway IEmailSender | | v v StripePaymentGateway EmailSender | | v v External API Email Provider<\/code><\/p>\n\n\n\nOrderService<\/code> can remain concrete if there is no reason to abstract it.<\/p>\n\n\n\n
\n\n\n\nThe Goal Isn’t Maximum Flexibility<\/h3>\n\n\n\n
Concrete by default \u2193 Identify real boundaries \u2193 Abstract meaningful variation \u2193 Register abstractions with DI \u2193 Keep infrastructure behind those boundaries<\/code><\/p>\n\n\n\n
\n\n\n\nConclusion<\/h2>\n\n\n\n
\n