Application Architecture and Domain Boundaries

A domain model owns business invariants. An application layer coordinates a use case and transaction. Infrastructure implements databases, queues, clocks, and HTTP clients. Delivery adapters translate HTTP, messages, or console commands into application requests.

Advanced C# work improves when you separate language syntax, runtime behavior, and application policy. Write down which layer owns the guarantee in this lesson. Then identify the observable evidence—a compiler rejection, test result, generated query, trace, or measurement—that would prove the model correct.

Feature-oriented vertical slices keep a use case’s endpoint, validation, handler, and tests close. Layering centralizes shared policy. These approaches can coexist if dependencies point inward and shared abstractions represent stable concepts rather than folders.

The starter isolates one part of the mental model so it can run in the browser. The exercise moves the same rule into a current local .NET project where packages, framework hosting, diagnostics, and multi-file tests are available.

using System;

interface IOrderStore { void Save(string orderId); }
class PlaceOrder
{
  private readonly IOrderStore store;
  public PlaceOrder(IOrderStore store) { this.store = store; }
  public void Execute(string id)
  {
      if (string.IsNullOrWhiteSpace(id)) throw new ArgumentException("Order id required.");
      store.Save(id);
  }
}
class MemoryStore : IOrderStore { public void Save(string id) { Console.WriteLine(id); } }
class Program { static void Main() { new PlaceOrder(new MemoryStore()).Execute("ORD-42"); } }

ORD-42

An interface for every class creates indirection without substitution. Generic repositories erase valuable query semantics. Domain entities coupled to controllers or DbContext become difficult to exercise independently. A shared utilities project often becomes an unmanaged dependency hub.

Classify each failure as a contract violation, transient operational failure, permanent dependency response, concurrency conflict, or programmer defect. That classification determines whether to reject, retry, compensate, cancel, or fail fast. A generic catch-and-continue policy destroys the information needed to make that decision.

Use architecture tests for forbidden dependencies, decision records for meaningful tradeoffs, and end-to-end tests at critical boundaries. Revisit structure when evidence shows friction rather than following a diagram as law.

Finish by making the result operable. Add structured diagnostics at the boundary, propagate cancellation, avoid sensitive data, and record SDK and dependency versions. Test the public behavior instead of private implementation details. If a framework or provider performs translation, serialization, concurrency, or I/O, include at least one test against the real production technology.

A senior-level review should be able to answer four questions: what contract is promised, who owns lifetime and cleanup, how failures become visible, and what evidence supports the design. If any answer depends on “the framework probably handles it,” inspect the documentation or runtime behavior and turn the assumption into a checked decision.