Table of Contents

ASP.NET Core

The ASP.NET Core section connects the architectural ideas in ASI Backbone Learning to practical application structure in modern .NET web applications.

The focus is not on teaching every ASP.NET Core feature.

Instead, this section examines how application structure can make security, governance, execution boundaries, and operational behavior easier to understand and maintain.

Section status: Focused ASP.NET Core learning is expanding. Start with Middleware Ordering Changes Behavior, continue with Secure-by-Default ASP.NET Core Configuration, then read Structured Logging Without Sensitive-Data Sprawl, Centralized Error Handling and Problem Details, Data-Access Boundaries and Transaction Reasoning with EF Core, Architecture Decision Records Preserve Architectural Reasoning, Architecture Decision Record Lifecycle, Review, Deprecation, and Supersession, and Working Repository ADR Case Study: NetCoreApplicationTemplate, then complete the Write and Revisit an Architecture Decision Record lab. Use the Foundational Tutorials when you want to connect application structure to governed execution.

Start Here

Middleware Ordering Changes Behavior is the first focused ASP.NET Core tutorial. It explains the two-direction request/response pipeline, short-circuiting, exception-handler coverage, authentication/authorization order, endpoint-routing boundaries, request logging, security headers, proxy correction, and rate-limiting placement.

Its companion sample includes both a corrected pipeline and a deliberately incorrect pipeline so the order-sensitive behavior is observable.

Continue with the Identify Middleware Ordering Problems lab to diagnose the incorrect sequence, repair a disposable copy, validate the changed behavior, and explain the ordering dependency.

Secure-by-Default ASP.NET Core Configuration then treats configuration as part of the application architecture and trust boundary. It covers explicit opt-in, startup validation, environment-specific behavior, secrets, safer failure choices, and configuration ownership boundaries.

Structured Logging Without Sensitive-Data Sprawl continues into operational diagnostics. It explains structured events, stable event identity, correlation, logging boundaries, exception logging, data minimization, volume/cardinality, and the difference between troubleshooting telemetry and governance audit evidence.

Centralized Error Handling and Problem Details then establishes one application-level exception boundary for unexpected failures, safe RFC 9457 Problem Details responses, deliberate status mapping, correlation with operational logs, and explicit HTTP translation of expected governance outcomes without converting those outcomes into exceptions. Its companion sample includes focused integration tests for safe 500 responses, known failure mapping, governance-result translation, correlation, and status-code Problem Details.

Data-Access Boundaries and Transaction Reasoning with EF Core continues from application behavior into durable state. It compares direct DbContext usage with meaningful persistence abstractions, explains default and explicit transaction boundaries, distinguishes generic database auditing from governance audit residue, examines SaveChanges interceptors, and keeps local relational atomicity separate from external side effects, idempotency, outbox/inbox patterns, and recovery.

Architecture Decision Records Preserve Architectural Reasoning then shifts from runtime structure to architectural memory. It explains when a decision deserves an ADR, what belongs in the record, how ADRs differ from other documentation, and how context, alternatives, consequences, and review conditions preserve reasoning that code alone cannot show.

Architecture Decision Record Lifecycle, Review, Deprecation, and Supersession continues from recording a decision to revisiting one. It explains common ADR states, the difference between deprecation and supersession, evidence that should trigger review, preservation of historical reasoning, implementation drift, migration periods, and lightweight review without unnecessary ceremony.

Working Repository ADR Case Study: NetCoreApplicationTemplate then follows two accepted decisions from general Learning principles into repository-specific constraints, ADR rationale, concrete code and configuration, alternatives, consequences, and review triggers. It uses the working repository as a specimen rather than a universal standard.

Complete the Write and Revisit an Architecture Decision Record lab to make a logging-related decision yourself, preserve its alternatives and consequences, define evidence-based review conditions, and then choose the correct lifecycle response after the scenario changes.

Architectural Areas

This section will continue to expand into topics such as:

Governed Execution in ASP.NET Core

A common application path is:

HTTP Request
   ↓
Authentication
   ↓
Authorization
   ↓
Application Logic
   ↓
Side Effect

For consequential operations, the application may benefit from a more explicit boundary:

HTTP Request
   ↓
Authenticated Actor
   ↓
Proposed Intent
   ↓
Policy Context
   ↓
Governance Decision
   ↓
Scoped Authority
   ↓
Host-Owned Execution
   ↓
Response + Audit Residue

The appropriate amount of structure depends on the application.

Not every endpoint requires a governance pipeline.

Before applying these ideas to an ASP.NET Core application, review:

For AI-assisted application scenarios, continue with:

Working ASP.NET Core Reference

The primary implementation reference is:

AsiBackbone/NetCoreApplicationTemplate

That repository provides a fuller ASP.NET Core reference architecture demonstrating production-oriented concerns such as:

  • Middleware organization
  • Structured logging
  • Security defaults
  • Configuration validation and environment handling
  • Error handling
  • Rate limiting
  • Authentication-ready design
  • Data-access patterns
  • Architecture Decision Records

Learning should explain the architectural lesson without reproducing the full application.

Current Status

The ASP.NET Core learning area now covers middleware ordering, secure-by-default configuration, structured logging, centralized error handling, data-access boundaries with EF Core transaction reasoning, introductory Architecture Decision Record reasoning, ADR lifecycle review, and a working-repository ADR case study. The middleware lesson is paired with an executable companion sample, focused invariant tests, and a beginner diagnostic lab; the configuration lesson establishes explicit opt-in, startup validation, environment behavior, secrets, safer failure, and configuration ownership; the logging lesson establishes structured operational events, correlation, diagnostic boundaries, sensitive-data minimization, and a deliberate separation between logs and governance audit evidence; the error-handling lesson adds a centralized IExceptionHandler/Problem Details boundary plus a runnable sample and focused integration tests; the data-access lesson connects durable governance state to DbContext, persistence abstractions, relational transactions, interceptors, provider-aware testing, and external-side-effect failure windows; the ADR introduction explains when architectural reasoning should be preserved, what a concise record contains, and why alternatives and consequences matter; the lifecycle lesson explains how accepted decisions can be reviewed, retained, deprecated, or superseded without erasing architectural history; and the NetCoreApplicationTemplate case study traces ADR-0001 and ADR-0002 into current implementation evidence while separating reusable principles from repository-specific choices. The intermediate ADR lab completes the path by requiring learners to author the reasoning and then classify a changed scenario as retention, deprecation, supersession, or implementation-only evolution.

Use the Foundational Tutorials for the governance model and NetCoreApplicationTemplate for a fuller application specimen.

Read it. Run it. Question it. Improve it.

Edit this page