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

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-계층화-아키텍처-layered-architecture	계층화 아키텍처 (Layered Architecture)	10_Wiki/Topics	verified	self	Layered Architecture N-tier Tiered Architecture	none	A	0.9	applied	architecture layering separation-of-concerns n-tier		2026-05-10	pending	language framework agnostic 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

@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

// 매 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)

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

@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)

// ❌ 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 · Django · ASP.NET Core
• Adjacent: Separation of Concerns · Dependency Injection · Repository Pattern

🤖 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