blazor
Blazor Server + Vertical Slice Architecture
Implement and evolve Blazor Server apps using vertical slices (feature-first), not layered architecture. Organize code by use case so each slice owns its UI, application logic, and data access. High cohesion inside a slice, low coupling between slices.
Target stack: modern .NET 8+ Blazor Server / Blazor Web App (Server). Prefer feature folders over Controllers/Services/Repositories layers. Avoid "god" services or generic repositories unless there is a proven cross-cutting need.
Project structure
- Top-level
Featuresfolder (or equivalent). - Under
Features, one folder per feature or use case:Features/Users/GetUserListFeatures/Users/UserDetailsFeatures/Events/ViewCreatedEvent
- Each feature folder contains everything specific to that use case:
- Blazor components / pages (
.razor, partial.razor.cs). - Request / command / query types and response / view models.
- Handler(s) — MediatR request handlers or an equivalent application-service class — implementing the business logic.
- Slice-specific helpers (mappers, validators) that are not truly cross-cutting.
- Blazor components / pages (
More from jonhilt/practical-engineer
tdd
Implement one theory through strict outside-in TDD, deriving tests from the spec brief. Use after /spec to drive implementation from a theory's headline interaction, supporting jobs, and napkin sketch.
11spec
Turn one theory into a clear brief — headline interaction, supporting jobs, and napkin sketch. The bridge between a theory and TDD. Use after /theories to specify one theory at a time.
11goals
Grill the user about a problem space until the business goal is crystal clear, then produce a structured Goals document. Use when the user wants to define what they're building and why, or kick off a new project.
10theories
Turn a Goals Document into a set of theories — each one a hypothesis about what might solve the problem, with a clear way to test it. Use after /goals to decide what to build and why.
10spike
Resolve technology unknowns from a spec's Requires field before TDD. Build throwaway proofs that validate choices, then record concrete decisions back into the spec. Use after /spec, before /tdd.
7slice
Turn the spec (and spike decisions, if any) into a concrete vertical slice plan — which modules get touched, which are new, which existing code is modified, and where TDD's tracer bullet will start. Use after /spec (or /spike) and before /tdd.
5