14 · REFACTOR
Take a monolith apart without breaking it.
A working but bloated design lands in front of you. Identify the smells, restructure to clean boundaries, apply separation of concerns — while keeping the system functionally equivalent.
Start refactoringMONOLITHIC
does too much
RIGID
hard to change
BLOATED
unnecessary complexity
FRAGILE
breaks easily
From one tangled class to clean boundaries.
«class» OrderManager
+ createOrder()
+ cancelOrder()
+ sendConfirmation()
+ processPayment()
+ updateInventory()
+ generateInvoice()
+ cacheOrder()
+ validateAddress()
+ applyDiscount()
+ logAction()
1 class, 10 responsibilities
«class» OrderService
+ createOrder()
+ cancelOrder()
«class» PaymentService
+ processPayment()
+ applyDiscount()
«class» NotificationService
+ sendConfirmation()
«class» InventoryService
+ updateInventory()
4 services, 1 responsibility each
Tag what you find before you fix it.
Structured refactoring starts with diagnosis. Apply smell tags to elements in the canvas — then restructure with purpose.
Smell Tags — apply to any canvas element
«class» OrderManager
+ createOrder() · + cancelOrder() · + processPayment()…
"Naming the problem before jumping to a fix is what separates structured refactoring from blind restructuring."
Structured, not scattered.
- 01
Study the monolithic design
Read the existing class diagram carefully. Understand what the system currently does — every method, every relationship, every dependency.
- 02
Identify refactoring opportunities
Tag elements with smell labels. Mark which classes are MONOLITHIC, which relationships make the design RIGID, where BLOAT accumulates, and what makes it FRAGILE.
- 03
Restructure the design
Extract classes and services. Define new boundaries. Allocate responsibilities cleanly. Apply Single Responsibility, Dependency Inversion, and Interface Segregation as you go.
- 04
Validate your refactored design
Run the structural validator. It checks that your refactored design is functionally equivalent, smell-free, and adheres to clean design principles.
Everything you need to restructure with confidence.
Real monolithic starting points
Each challenge begins with a realistic, densely-packed monolithic design — not a toy example. The starting design actually works; your job is to make it clean.
Smell identification tags
Apply MONOLITHIC, RIGID, BLOATED, and FRAGILE tags directly to canvas elements. Tagging is part of the exercise — diagnosis before surgery.
Free-form restructuring
No prescribed path. Extract classes, define interfaces, create new service boundaries — the canvas gives you full structural freedom.
Validation feedback
The validator checks structural health: smell resolution, responsibility allocation, and functional equivalence. Specific, actionable, non-prescriptive.
SOLID principles naturally applied
Refactoring well is applying SOLID. SRP emerges from extracting classes. DIP from introducing interfaces. OCP from decoupling change paths.
Functional equivalence constraint
The refactored design must do everything the original did — just structured better. The constraint keeps you honest: you can't delete functionality to simplify.
Who should practice Refactor?
Mid-level engineers moving to senior
Senior interviews test whether you can critique and improve existing designs — not just build green-field. Refactor trains exactly that skill: seeing what's wrong and fixing it precisely.
Engineers targeting FAANG / top-tier companies
Structured refactoring under time pressure is a proxy signal for senior and staff-level engineering judgement. Top companies test it because legacy improvement is real daily work.
Backend engineers practicing system design
If your system design rounds are strong but your LLD rounds are weak, Refactor is the gap-filler. It bridges the two: structural thinking at the code level.
Self-taught engineers learning design principles
SOLID principles taught through textbooks are abstract. Refactor makes them visceral — you see exactly what breaks when SRP is violated, and you fix it yourself.
Tag the smells. Untangle the design.
The monolith is already on the canvas. Your job is to make it something a future engineer can actually work with.
Start refactoringFAQ
Questions people ask
→ Explore more