LESSON 8.4

MVC, MVVM and layered architecture

Separate presentation, application orchestration, and core business domain logic with architectural patterns: MVC, MVVM, and clean 3-tier layering.

6 min read

When applications grow organically, code often clumps into massive UI files or database scripts: SQL queries inside React components, HTTP session parsing inside domain calculations, and presentation formatting inside database triggers. Any change to the database breaks the frontend, and any change to the UI breaks domain logic.

The problem

snippet.js

1 // Tangled layers: presentation, domain, and database all in one file
2 function handleButtonClick(req, res) {
3   // 1. Presentation & HTTP parsing
4   const { userId, amount } = req.body;
5   // 2. Database access
6   const user = db.query("SELECT * FROM users WHERE id = ?", [userId]);
7   // 3. Domain business logic
8   if (user.balance < amount) return res.send("No funds");
9   user.balance -= amount;
10   // 4. Persistence
11   db.query("UPDATE users SET balance = ?", [user.balance]);
12   // 5. HTML presentation formatting
13   res.send(`<h1>Success! New balance: $${user.balance}</h1>`);
14 }

JavaScript · 14 lines

UTF-8

The pattern

Layered Architecture divides an application into concentric boundaries:

Domain Layer: Pure business entities and rules. No external dependencies.
Application / Use Case Layer: Orchestrates domain entities to achieve specific use cases (e.g. TransferFundsUseCase).
Infrastructure Layer: Implements technical details (Database, Mailers, HTTP clients).
Presentation Layer (MVC/MVVM): Handles user interaction, rendering, and input parsing.

Laying out the diagram…

Dependencies flow strictly inwards. DomainModel remains pure, independent of UI or DB drivers.

In code

When to use it, and when not to

Use Layered Architecture when:

You are developing medium-to-large business applications that will evolve over years.
Different teams work on the frontend, business rules, and database schema.
You want to replace your database driver, web framework, or UI library without rewriting business rules.

Don't use Layered Architecture when:

You are building a 2-day prototype, CLI script, or simple CRUD tool: strict layering adds unnecessary files and mapping boilerplate.

Where you have already seen it

Every major web framework enforces layering: Nest.js separates Controllers, Services, and Repositories; Spring Boot standardizes @RestController -> @Service -> @Repository; Clean Architecture (Uncle Bob) and Hexagonal Architecture (Ports and Adapters) are formalized evolutions of this layered principle.

Layered Architecture vs Facade: An Application Service often acts as a Facade over several domain entities and infrastructure services.
MVC vs MVVM: MVC is typically request-driven (traditional web apps). MVVM is data-binding-driven (modern reactive frontend single-page apps).

Quick check

Why should the Domain layer have NO imports from the Presentation or Database frameworks?

Try it

Library Management LLD

Structure a library management system into separated Domain entities, Use Case services, and Storage repositories.

Check your understanding

1.In clean layered architecture, what is the fundamental rule regarding dependency direction?
2.What is the primary difference between a Controller in MVC and a ViewModel in MVVM?
3.What belongs in the Application (Use Case) layer versus the Domain layer?

Practice it

Library Management LLDModel titles, physical copies, loans and reservations without double lending.Shopping Cart Domain LLDModel cart mutations, version checks and reproducible price quotes.

Your notes

1 // 1. DOMAIN LAYER: Pure business rules & entities (Zero external dependencies) 2 class BankAccount { 3 #id; 4 #balance; 5 6 constructor(id, balance) { 7 this.#id = id; 8 this.#balance = balance; 9 } 10 11 withdraw(amount) { 12 if (amount <= 0) throw new Error("Amount must be positive"); 13 if (this.#balance < amount) throw new Error("Insufficient funds"); 14 this.#balance -= amount; 15 } 16 17 get balance() { return this.#balance; } 18 get id() { return this.#id; } 19 } 20 21 // 2. APPLICATION LAYER: Orchestration / Use Case 22 class WithdrawMoneyUseCase { 23 #accountRepo; 24 25 constructor(accountRepo) { 26 this.#accountRepo = accountRepo; 27 } 28 29 execute(accountId, amount) { 30 const account = this.#accountRepo.findById(accountId); 31 if (!account) throw new Error("Account not found"); 32 33 account.withdraw(amount); // Pure domain rule executed 34 this.#accountRepo.save(account); 35 36 return { success: true, remainingBalance: account.balance }; 37 } 38 } 39 40 // 3. INFRASTRUCTURE LAYER: In-memory repository implementing domain contract 41 class InMemoryAccountRepository { 42 #store = new Map(); 43 findById(id) { return this.#store.get(id); } 44 save(account) { this.#store.set(account.id, account); } 45 } 46 47 // 4. PRESENTATION LAYER: Controller / ViewModel 48 class AccountController { 49 #useCase; 50 constructor(useCase) { this.#useCase = useCase; } 51 52 handleWithdrawalRequest(payload) { 53 try { 54 const result = this.#useCase.execute(payload.accountId, payload.amount); 55 return { status: 200, body: `Success: $${result.remainingBalance} remaining` }; 56 } catch (err) { 57 return { status: 400, body: `Error: ${err.message}` }; 58 } 59 } 60 } 61 62 // Assembly 63 const repo = new InMemoryAccountRepository(); 64 repo.save(new BankAccount("ACC-1", 100)); 65 66 const useCase = new WithdrawMoneyUseCase(repo); 67 const controller = new AccountController(useCase); 68 69 const res1 = controller.handleWithdrawalRequest({ accountId: "ACC-1", amount: 40 }); 70 console.assert(res1.status === 200); 71 72 const res2 = controller.handleWithdrawalRequest({ accountId: "ACC-1", amount: 200 }); // Exceeds balance 73 console.assert(res2.status === 400); 74 75 console.log(res1.body); 76 console.log(res2.body);

1 public class Example { 2 static final class BankAccount { 3 private final String id; 4 private double balance; 5 6 BankAccount(String id, double balance) { this.id = id; this.balance = balance; } 7 8 public void withdraw(double amount) { 9 if (amount <= 0) throw new IllegalArgumentException("Invalid amount"); 10 if (balance < amount) throw new IllegalStateException("Insufficient funds"); 11 balance -= amount; 12 } 13 14 public double getBalance() { return balance; } 15 public String getId() { return id; } 16 } 17 18 interface AccountRepository { 19 BankAccount findById(String id); 20 void save(BankAccount a); 21 } 22 23 static final class WithdrawUseCase { 24 private final AccountRepository repo; 25 WithdrawUseCase(AccountRepository repo) { this.repo = repo; } 26 27 record Result(boolean success, double newBalance) {} 28 29 public Result execute(String id, double amount) { 30 var acc = repo.findById(id); 31 if (acc == null) throw new IllegalArgumentException("Not found"); 32 acc.withdraw(amount); 33 repo.save(acc); 34 return new Result(true, acc.getBalance()); 35 } 36 } 37 38 static final class InMemoryRepo implements AccountRepository { 39 private final java.util.Map<String, BankAccount> store = new java.util.HashMap<>(); 40 public BankAccount findById(String id) { return store.get(id); } 41 public void save(BankAccount a) { store.put(a.getId(), a); } 42 } 43 44 public static void main(String[] args) { 45 var repo = new InMemoryRepo(); 46 repo.save(new BankAccount("ACC-1", 100.0)); 47 48 var useCase = new WithdrawUseCase(repo); 49 var res = useCase.execute("ACC-1", 40.0); 50 51 if (res.newBalance() != 60.0) throw new AssertionError(); 52 System.out.println("Remaining balance: " + res.newBalance()); 53 } 54 }

The problem

The pattern

In code

When to use it, and when not to

Where you have already seen it

Related patterns

Check your understanding

Practice it

The problem

The pattern

In code

When to use it, and when not to

Where you have already seen it

Related patterns

Check your understanding

Practice it