Week 3 Part II · API and Persistence

SOLID Principles and Clean Code

Instructor lesson plan: lecture (2 h) and practice (2 h).

Learning objectives

Apply SOLID principles to service and domain code.
Recognize coupling, mixed responsibilities, and unstable abstractions.
Refactor toward cohesive classes and explicit dependencies.
Use small design checks to preserve behavior while improving structure.

Tools this week

.NET test runnercode analyzersrefactoring toolsarchitecture sketches

🎓Lecture · 2 hours

0:00-0:10	10 min	RetrievalStudents show one entity and one invariant from week 2.
0:10-0:35	25 min	Single responsibility and cohesion Reasons to change as the practical test. Spotting classes that mix persistence, validation, and business rules.
0:35-0:55	20 min	Open-closed and strategyReplace conditional policy blocks with named policies only when variation is real.
0:55-1:10	15 min	Liskov and interface segregationContracts, substitutability, and focused interfaces.
1:10-1:20	10 min	Break
1:20-1:45	25 min	Dependency inversion High-level policy should not depend on low-level details. Interfaces owned by the application need, not by infrastructure convenience.
1:45-2:00	15 min	Clean code in teamsNames, small functions, reviewability, and refactoring as a normal activity.

Common misconception to confront.

Students often think: every class needs an interface.
Set it straight: introduce an interface when it protects a boundary, supports variation, or protects a boundary.

Check for understanding

What is a reason to change?

A business, policy, persistence, integration, or presentation concern that would force editing the class.

Who should own an abstraction?

Usually the higher-level policy that needs the behavior, not the low-level implementation that happens to provide it.

Key takeaways.

SOLID is a decision aid, not a checklist ritual.
Refactoring must preserve tested behavior.
Interfaces are valuable at boundaries.

📚Reading & resources

Clean Architecture, SOLID chapters Robert C. Martin's vocabulary for dependency direction and boundaries.
Refactoring, ch. 1 Fowler's workflow for behavior-preserving change.
Architectural principles Microsoft guidance on separation of concerns and dependency inversion.

💻Practice · 2 hours

0:00-0:20	20 min	Smell huntReview a deliberately messy service and identify responsibilities.
0:20-0:55	35 min	Guided refactor Extract policies and dependencies. Keep behavior stable after every small step.
0:55-1:10	15 min	Team reviewEach team names one class in its project with too many reasons to change.
1:10-1:20	10 min	Break
1:20-1:50	30 min	Project refactorTeams refactor one domain or service area and document the preserved behavior.
1:50-2:00	10 min	Project-integration briefSubmit a short note explaining the refactor and why it improves maintainability.

Project integration (this week)

Refine domain model and service boundaries.
Refactor at least one mixed-responsibility class.
Document the behavior protected by the refactor.