Dependency direction and layer ownership
5 katasMove policy, contracts, configuration, and persistence concerns to the side of the boundary that owns them, then make every dependency point inward.
Clean Architecture practice with executable rules
C# architecture exercises that make the arrows executable
Refactor realistic, multi-file C# systems until dependencies point the right way. Behavior tests protect what the code does while architecture rules grade layers, ports, modules, and cycles across 19 focused katas.
Five free previews. No project download or local SDK.
- architecture exercises
- 19
- free previews
- 5
- guided path steps
- 13
From diagram to dependency graph
Practice the boundary, not the vocabulary
Clean Architecture and hexagonal architecture are easy to recognize in a diagram. The useful skill is noticing when one concrete type, misplaced interface, or convenient callback bends an arrow outward in working code.
Each kata gives you that violation in a bounded project. You decide which side owns the abstraction, move the seam, and keep the system's behavior green while structural checks inspect the submitted assembly.
Start with the ports-and-adapters guide or read dependency inversion in C#, then turn the idea into a rep.
Ports and adapters
Four architecture skill families
Train the dependency decisions that code review catches too late
The catalog moves from one wrong edge to realistic cycles across several modules. Every family repeats a structural judgment until the invalid shape becomes visible before the analyzer names it.
Ports, adapters, and composition
6 katasPlace ports beside the core need they express, keep adapters outside, and leave concrete wiring to the composition root instead of the domain.
Modules, contracts, and cycles
6 katasBreak circular feature dependencies, protect module internals, and publish contracts that share facts without coupling one module to another's implementation.
CQRS and interface boundaries
2 katasSeparate reads from writes and split oversized interfaces so each consumer sees only the capability its side of the architecture is allowed to use.
Free C# architecture exercises
Fix five real boundary failures in the browser
Open any preview, inspect the working starter, and refactor until behavior and design are both green. These are addressable exercises, not screenshots or solution walkthroughs.
- 01 Medium
Config Is Infrastructure
The shipping core reads a framework configuration type directly, welding the domain to infrastructure. Invert it behind a core-owned options port, and don't just rename the framework wrapper into the core, which trips a second rule.
Open this architecture kata → - 02 Medium
Move the Port Home
A `*Port` abstraction is declared beside its adapter, so the core reaches outward to see its own port. Move the single port into the core; duplicating it leaves a stray copy that fails the role-placement rule.
Open this architecture kata → - 03 Medium
The Layer Skip
A controller reaches past the application layer straight into infrastructure for the order total. Route the call back through the middle layer with a port the application owns; a thin pass-through that still touches infrastructure only moves the smell, it doesn't remove it.
Open this architecture kata → - 04 Medium
Two Sides of the Hexagon
A driving (web) adapter reaches the driven (persistence) adapter directly for a quick existence check. Inject the repository "via its interface" and you'll find the seam is still on the wrong side of the hexagon.
Open this architecture kata → - 05 Hard
Break the Checkout Cycle
Orders, Pricing and Promotions import each other in a three-hop cycle while Pricing also reaches into Inventory's internals. Moving the obvious call only rotates the cycle; hoist the shared vocabulary into a kernel leaf and reach Inventory through its published port to turn every rule green.
Open this architecture kata →
The architecture suite
Layers only depend inward
Infrastructure -> Domain only
✓ holding
Handlers are named and sealed
every IRequestHandler implementation
✓ holding
Domain must not depend on Infrastructure
Acme.Domain.Order -> Acme.Infrastructure
✗ 1 violation
✓ 2 / 3 rules green ✗ Build red, merge blocked
Behavior green, architecture red
A compiling workaround does not pass
A kata can require a namespace to depend only inward, forbid presentation from skipping a layer, keep module internals private, require a core-owned interface, or reject cycles in the module graph.
Hidden behavior tests make sure the feature still works. Separately authored architecture rules inspect the code's shape. Moving the wrong type, duplicating an interface, or merely renaming the forbidden role leaves a precise red verdict.
See how structural grading works and why architecture fitness functions turn a diagram into a build constraint.
The architecture practice loop
Change the graph without changing the feature
01
Read the working system
Inspect a small multi-file C# codebase, its behavior, and the boundary that has been crossed. The starter compiles; the architecture is the bug.
02
Move the dependency
Refactor the code in the browser. Introduce or relocate a port, split a contract, or break a cycle while keeping the observable behavior intact.
03
Prove the design
Submit against hidden behavior tests and executable architecture rules. Both must pass: a renamed violation is still a violation.
Prefer a curriculum? The Pro Architecture Boundaries path orders 13 katas from policy ownership through ports, module contracts, and dependency cycles.
C# architecture exercise FAQ
Before you move the first dependency
What are C# architecture exercises?
They are small, working, multi-file C# systems with a structural flaw. You refactor the dependency graph without changing behavior, then executable rules verify layer isolation, dependency direction, port placement, module boundaries, and related design constraints.
What Clean Architecture skills can I practice?
The 19 exercises cover inward dependency direction, domain and infrastructure separation, ports and adapters, composition roots, layer skips, module cycles, shared contracts, CQRS boundaries, and interface segregation.
Are the C# architecture exercises free?
Five architecture katas are free previews: Config Is Infrastructure, Move the Port Home, The Layer Skip, Two Sides of the Hexagon, and Break the Checkout Cycle. Pro unlocks all 19 exercises and the guided Architecture Boundaries path.
Do these include hexagonal architecture exercises?
Yes. Several exercises train ports and adapters directly: the core owns its ports, driving and driven adapters stay on opposite sides, and concrete wiring remains outside the domain. Other exercises apply the same inward-dependency rule to layered and modular systems.
Are these system-design interview katas?
No. These are code-level architecture exercises, not open-ended whiteboard scenarios. You edit a real C# project and receive a deterministic verdict from behavior tests and structural rules.
Do I need Visual Studio or the .NET SDK installed?
No. The editor, compiler, behavior tests, and architecture checks run from the browser in a disposable server-side environment.
Looking for broader practice? Browse all C# coding challenges across performance, data access, refactoring, architecture, security, and testing.
Make the dependency graph prove your design
Start with Two Sides of the Hexagon and let behavior tests plus architecture rules tell you when every boundary is genuinely back in place.
Try a hexagonal kata free