Software Architecture
Structure systems deliberately: layering, SOLID, clean architecture, patterns, and honest guidance on when each is the wrong choice.
Prerequisites
- Solid C# including interfaces
- Experience building at least one real application
About this course
Architecture is often taught as a catalogue of patterns to apply. This course treats it as a series of trade-offs instead, because a pattern used without its motivating problem usually adds cost and no benefit.
Every topic answers three questions: what problem does this solve, when should you use it, and when should you deliberately not. That third question is the one most material omits, and it is the one that prevents a small application being buried under structure it never needed.
The advanced modules cover distributed concerns — messaging, event-driven design, microservices, resilience — with particular attention to the operational cost they introduce, so you can make that choice with your eyes open.
Course roadmap
All 19 lessons are written and available.
Module 01
Architecture Foundations
What architecture is responsible for, and the one habit that underpins the rest.
- 01SOLID PrinciplesApply each principle where it helps, and name the cost of overusing it.22 min
- 02Dependency InversionDepend on abstractions so infrastructure can change independently.18 min
- 03Clean ArchitectureKeep business rules independent of frameworks and databases.20 min
- 04Modular ArchitectureDraw module boundaries inside one application before splitting it.20 min
- 01Repository PatternAbstract data access, and decide honestly whether you need to.20 min
- 02Factory PatternCentralise construction when creating an object is genuinely complex.16 min
- 03Strategy PatternSwap an algorithm at run time instead of branching on type.18 min
- 04Adapter PatternWrap an external interface so it does not leak through your code.18 min
- 05Observer PatternNotify interested parties without coupling them to the source.18 min
Module 04
Distributed Systems
What you gain and what you take on when a system stops being one process.
- 01CQRSSeparate reads from writes, and recognise when this is overkill.22 min
- 02Event-Driven ArchitectureCommunicate through events, accepting eventual consistency.22 min
- 03MicroservicesWeigh independent deployment against distributed complexity.22 min
- 04API GatewayGive clients one entry point to many services.20 min
- 05Messaging and QueuesDecouple producers from consumers and absorb load spikes.22 min
- 06Caching StrategiesCache effectively and handle invalidation deliberately.22 min
- 07ResilienceApply timeouts, retries and circuit breakers so failure degrades gracefully.22 min
Projects for this course
Document Management Platform
An architecture exercise: file storage, versioning, permissions and background processing, structured to stay maintainable.
Multi-Tenant SaaS Application
The hardest project here. Serve several customers from one system without ever leaking data between them.
On completion
What you should take away
- Architecture is about trade-offs, and naming them is most of the work
- Dependencies pointing inwards is what makes business logic testable
- Patterns solve specific problems; applied without the problem they are pure cost
- Distributed architectures trade local complexity for operational complexity
Have a project worth talking through?
Tell us what you're building or what's slowing your current system down. We'll give you a direct read on scope and approach.