Teaching Clean Architecture without turning it into ceremony

Start with a pressure, not a diagram

Students understand boundaries once a feature forces a decision. A payment integration, an approval workflow, or a new delivery channel gives the layers a real job to do.

The domain should explain itself

The business rules should be readable without knowing whether the data lives in SQL Server, a mock, or a remote API. That is the useful part of separation—not the number of folders in a solution.

Keep the trade-off visible

A smaller project does not need every abstraction. The point is to keep decisions replaceable when the product earns that complexity.

Build, then name it

I prefer students to feel the pain first, solve it, and then learn the pattern's name. The name sticks because it explains something they already built.