Phase 4레슨 16

Layered Architecture

Presentation, Business, Persistence, Database — 가장 전통적인 아키텍처

💡ELI5·

회사 조직도와 계층

Presentation  (UI — 사용자 요청/응답)
     ↓
Business      (비즈니스 로직 — 서비스)
     ↓
Persistence   (DB 접근 — Repository, DAO)
     ↓
Database      (데이터 저장)

💡 비유 — 회사 조직도: 영업팀(Presentation)이 고객 응대 → 기획팀(Business)이 처리 → 회계팀(Persistence)이 기록 → 창고(Database). 위에서 아래로만 흐르고, 아래 팀은 위 팀을 모른다.

🔬Deep Dive·

4계층 구조

계층	역할	예시
Presentation	사용자 입력, 화면 렌더링, API 엔드포인트	Controller, View, React Component
Business	비즈니스 규칙, 도메인 로직	Service, Domain Model
Persistence	DB 조회/저장, ORM 매핑	Repository, DAO, Entity
Database	데이터 저장	MySQL, PostgreSQL

// Presentation
class UserController {
  getUser(id: string) {
    return userService.getUser(id); // → Business
  }
}

// Business
class UserService {
  getUser(id: string) {
    return userRepository.findById(id); // → Persistence
  }
}

// Persistence
class UserRepository {
  findById(id: string) {
    return db.query('SELECT * FROM users WHERE id = ?', id);
  }
}

🔬Deep Dive·

Anemic Domain Model — 흔한 함정

Layered Architecture에서 비즈니스 계층이 'Service' 클래스로만 구성되고, 도메인 객체는 단순 데이터 홀더(getter/setter만 있는 DTO)가 되는 현상. 실제 로직은 Service나 Repository(SQL)에 흩어진다. 이를 Anemic Domain Model이라 한다.

문제: 비즈니스 규칙이 SQL이나 Service에 섞여 있어, 도메인 변경 시 여러 곳을 수정해야 하고 테스트가 어렵다. Martin Fowler는 이를 안티 패턴으로 분류했다.

⚖️Trade-off·

Layered의 장단점

장점	단점
이해와 구현이 쉬움	비즈니스 로직이 DB에 종속
빠른 개발 (CRUD에 적합)	Anemic Domain Model 빠지기 쉬움
모든 계층이 같은 프로젝트	계층 간 결합도 증가
작은 팀에 적합	도메인 복잡 시 유지보수 비용 급증

❓ 체크포인트 질문

1.Layered Architecture의 각 계층이 의존하는 방향은?
2.Layered Architecture의 가장 흔한 안티 패턴은?
3.Layered Architecture가 작은 프로젝트에 적합한 이유는?
4.Layered Architecture가 커지면서 발생하는 문제는?
5.Layered에서 Clean/Hexagonal로 넘어가는 시점은?

← 이전

Consensus (Raft, Paxos)

Clean Architecture