Skip to content

Lesson 12 — Architecture and production readiness

Objective

Evolve the tracker into defensible feature boundaries and reason through runtime, infrastructure, and operational failure.

Prerequisites

Applied evidence from components, state, DI, routing, forms, HTTP, RxJS, testing, and performance.

Mental model

Architecture assigns ownership and isolates expected change. A boundary is valuable when it clarifies dependencies, lifetime, trust, failure, or deployment—not because a diagram expects another layer.

Why it exists

Production systems must remain operable under slow networks, invalid data, partial failure, security threats, accessibility needs, deployment change, and team growth.

Working model: components call stores, stores call repositories, repositories call infrastructure.

Engineering reality: useful boundaries follow domain and volatility. Universal base repositories/stores can add coupling; small explicit designs often age better.

Minimal example

Trace one feature through:

URL → component/view → feature state → repository → HTTP/storage → backend → logs/metrics → deployment

At every arrow record owner, contract, trust boundary, failure behavior, and evidence.

Real-world usage

Feature organization, DTO mapping, global/feature error handling, SSR/hydration, authorization assumptions, observability, and migration all cross code/runtime/operations.

Common mistakes

  • organizing only by technical type or creating global dumping folders;
  • leaking URLs/serialization into components;
  • treating client guards as authorization;
  • logging sensitive user data;
  • hiding recoverable failures behind global handling;
  • adding abstractions without a change they isolate;
  • choosing SSR without browser-global and hydration analysis.

Mini lab

Task: Draw tracker data flow; organize domain features; isolate transport DTOs; audit accessibility/security; add boundary error reporting; assess SSR/hydration; write an ADR with options and consequences.

Constraints: no secrets or backend authorization assumptions in client code; every async feature covers loading/empty/error/retry; state lifetime and subscription teardown are explicit.

Expected result: the design explains scalability, reliability, observability, latency, security, cost, deployment/rollback, and backward compatibility proportionally to risk.

Hint 1

For each abstraction ask which likely change or failure it isolates.

Hint 2

Keep recoverable feature errors local; reserve application-boundary reporting for uncaught failures and diagnostics.

Solution direction — last resort

Prefer explicit feature boundaries with shared presentation and core cross-cutting capabilities. Add indirection for multiple implementations, volatile boundaries, or clear test value.

Verification

Run a “2 AM” scenario: SSR startup crashes on localStorage, one API slows down, and a deployment introduces malformed DTOs. Identify signals, containment, user behavior, rollback, and follow-up evidence.

Mastery evidence: produce an ADR, trace failure across layers, and revise a recommendation when constraints change.

Bloom challenge

  1. Understand: owner, contract, trust, and lifetime boundaries.
  2. Apply: map one feature end to end.
  3. Analyze: diagnose a cross-layer production failure.
  4. Evaluate: feature/global state, CSR/SSR/SSG, and abstraction options.
  5. Create: design authentication addition with threat boundaries, backend enforcement, telemetry, rollout, and rollback.

Summary

Production Angular judgment connects framework choices to browser, network, infrastructure, operations, and organizational change.

Spaced review

Retrieve all earlier lessons while tracing the feature. Any weak explanation becomes a targeted review, not a full-course reread.

What comes next

Attempt the production capstone, then use the mastery assessment.