2nd/10_Wiki/Topic_Programming/Programming & Language/계층화 아키텍처 (Layered Architecture).md

---
id: wiki-2026-0508-계층화-아키텍처-layered-architecture
title: 계층화 아키텍처 (Layered Architecture)
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [Layered Architecture, N-tier, Tiered Architecture]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
verification_status: applied
tags: [architecture, layering, separation-of-concerns, n-tier]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
  language: agnostic
  framework: Spring/.NET/Django
---

# 계층화 아키텍처 (Layered Architecture)

## 매 한 줄
> **"매 application 을 horizontal layer (presentation / business / persistence / data) 의 stack 으로 조직"**. 매 가장 흔한 default architecture — 매 simple, 매 onboarding 쉬움. 매 large-scale 에서 coupling/performance 한계 발생 → microservice/hexagonal 로 진화.

## 매 핵심

### 매 표준 layer
- **Presentation**: UI / REST controller / GraphQL resolver. 매 input 의 validation + serialization.
- **Business / Service**: domain logic, transaction boundary, orchestration.
- **Persistence / Repository**: ORM, query, cache.
- **Data**: DB, file, message broker.

### 매 strict vs relaxed
- **Strict layering**: 매 layer N 은 layer N-1 만 호출 가능. 매 testability 좋음.
- **Relaxed**: layer skip 가능 (e.g. controller → repository 직접). 매 anti-pattern 으로 간주.

### 매 응용
1. Spring Boot 의 @Controller / @Service / @Repository.
2. Django 의 view / business / model.
3. Clean Architecture 의 adapter ring 변형.
4. .NET 의 N-tier WebAPI / BLL / DAL.

## 💻 패턴

### Spring Boot 의 표준 3-layer
```java
@RestController
@RequestMapping("/orders")
public class OrderController {
    private final OrderService service;
    public OrderController(OrderService s) { this.service = s; }

    @PostMapping
    public OrderDto create(@RequestBody @Valid CreateOrderReq req) {
        return service.create(req);
    }
}

@Service
public class OrderService {
    private final OrderRepo repo;
    @Transactional
    public OrderDto create(CreateOrderReq req) {
        Order o = Order.from(req);
        return OrderDto.from(repo.save(o));
    }
}

@Repository
public interface OrderRepo extends JpaRepository<Order, Long> {}
```

### DTO ↔ Domain 매 boundary
```java
// 매 controller 는 DTO 만, service 는 domain entity 만 다룬다.
public record CreateOrderReq(String sku, int qty) {}
public record OrderDto(Long id, String sku, int qty, String status) {
    public static OrderDto from(Order o) {
        return new OrderDto(o.getId(), o.getSku(), o.getQty(), o.getStatus().name());
    }
}
```

### Repository abstraction (testability)
```java
public interface OrderRepo {
    Order save(Order o);
    Optional<Order> findById(Long id);
}
// 매 unit test 의 Stub repository 의 inject:
class StubOrderRepo implements OrderRepo { /* in-memory */ }
```

### 매 cross-cutting (logging / tx / auth) 의 AOP
```java
@Aspect
@Component
class AuditAspect {
    @Around("@annotation(Audited)")
    public Object audit(ProceedingJoinPoint pjp) throws Throwable {
        long t0 = System.nanoTime();
        Object result = pjp.proceed();
        log.info("{} took {}ns", pjp.getSignature(), System.nanoTime() - t0);
        return result;
    }
}
```

### Layer 의 dependency rule (안티: upward call)
```java
// ❌ Service 가 Controller 호출 X
// ❌ Repository 가 Service 호출 X
// ✅ 매 한 방향: presentation → service → persistence
```

## 매 결정 기준
| 상황 | Approach |
|---|---|
| CRUD-heavy MVP | 매 layered (default 선택) |
| 매 complex domain logic | hexagonal / clean architecture |
| 매 high decoupling 필요 | event-driven / CQRS |
| 매 large team / bounded context | microservice |
| 매 simple script | 매 layer X — single file |

**기본값**: 매 small/medium app 은 **3-layer (controller / service / repository)** + DI + DTO boundary.

## 🔗 Graph
- 부모: [[Software Architecture]]
- 변형: [[Hexagonal Architecture]] · [[Clean Architecture]] · [[Onion Architecture]]
- 응용: [[Spring Boot]] · [[ASP.NET Core]]
- Adjacent: [[Separation of Concerns]] · [[Dependency Injection]]

## 🤖 LLM 활용
**언제**: scaffolding generation, layer 위반 review, refactor towards layered.
**언제 X**: 매 trivial CRUD — boilerplate overhead.

## ❌ 안티패턴
- **Anemic Service**: 매 service 가 단순 repo passthrough — domain logic 누락.
- **Smart Controller**: business logic 의 controller 누수.
- **Layer skip**: controller 가 repo 직접 호출.
- **God Service**: 매 service class 가 5000+ lines — bounded context 분할 필요.

## 🧪 검증 / 중복
- Verified (Richards *Software Architecture Patterns* 2nd ed. 2022).
- 신뢰도 A.

## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — layered patterns + Spring example + anti-patterns |