00 · Monolith (as-is)
The legacy XYZ tool: one Blazor/.NET process, one shared database, synchronous full-page postbacks. Any change touches everything.
Every architectural consideration in this workshop, rendered as an interactive sequence diagram: the legacy baseline, the cross-cutting microservices flows (shared by all flavors), each of the three frontend flavors (A single Static Web App, B composition shell, C self-contained systems), and the delivery and migration paths. Building blocks are cited on the References page.
The legacy XYZ tool: one Blazor/.NET process, one shared database, synchronous full-page postbacks. Any change touches everything.
A write returns the authoritative result immediately; the read model catches up asynchronously via the outbox and an idempotent projector.
Domain events (a recalculation) and external feeds (Azure Updates / Service Health / Marketplace) converge on a Redis backplane and stream to the browser.
The approval matrix (EP → OMP → RMP → NMP) runs as a session-based saga, ordered per request, with compensation on rejection.
APIM validates the JWT at the edge; each slice re-checks a resource-level policy (right market, no self-approval).
One Static Web App serves the whole SPA; feature folders map to slices. Simplest, best for pixel parity and one FE team.
A thin shell exposes named slots and loads independently deployed slice remotes at runtime; a bad remote degrades to a placeholder.
No SWA. A dumb Frame service fetches HTML fragments in parallel from each slice's container (each owns UI + API + data) and streams the composed page.
One immutable image is promoted by digest through the rings; rollback is a traffic shift, not a rebuild.
New slices run beside the monolith behind one edge. Migrated paths route to slices (with shadow comparison); the rest still hit the monolith.