핵심 인사이트 (3줄 요약)

  • **제프리 팔레르모(Jeffrey Palermo)**가 제안한 아키텍처로, 도메인(Domain)을 중심에 두고 모든 외부 인프라 의존성을 외부 계층으로 밀어낸 구조임.
  • **의존성 역전(DIP)**을 핵심 원리로 사용하여 비즈니스 로직이 데이터베이스나 프레임워크에 의존하지 않도록 설계함.
  • 도메인 모델(Domain Model)과 도메인 서비스(Domain Services)를 핵심 계층으로 보호하여 응집도를 높이고 기술적 세부사항을 격리함.

Ⅰ. 개요 (Context & Background)

  • 기존의 계층형 아키텍처가 데이터베이스(Infrastructure)에 강하게 의존하는 문제를 해결하기 위해 고안되었으며, '클린 아키텍처'의 근간이 되는 모델 중 하나임.
  • 애플리케이션의 핵심 로직이 하위 인프라(DB, UI)가 아닌 추상화된 인터페이스에 의존하도록 설계하여 시스템의 유연성을 극대화함.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

[ Onion Architecture Layers ]

        /-------------------------------------------\
        |  Infrastructure (DB, Web, File, UI)        | <--- Infrastructure
        |  /-------------------------------------\  |
        |  |  Application Services (Use Cases)   |  | <--- Application
        |  |  /-----------------------------\     |  |
        |  |  |  Domain Services (Interfaces) |     |  | <--- Domain Services
        |  |  |  /-------------------\      |     |  |
        |  |  |  |   Domain Model    |      |     |  | <--- Core
        |  |  |  | (Entities, VO)    |      |     |  |
        |  |  |  \-------------------/      |     |  |
        |  |  \-----------------------------/     |  |
        |  \-------------------------------------/  |
        \-------------------------------------------/

* 의존성 방향 (Dependency Direction): Inward (All layers depend on inner layers)
  • Domain Model (Core): 시스템의 상태와 행위를 정의하는 엔티티(Entity) 및 값 객체(VO). 가장 순수한 비즈니스 로직.
  • Domain Services: 도메인 모델 간의 협력을 담당하며, 특정 도메인 로직을 수행하기 위한 인터페이스 정의.
  • Application Services: 사용자의 요청을 처리하고 도메인 로직을 조합(Orchestration)하는 계층.
  • Infrastructure: 데이터베이스, 파일 시스템, 외부 API, UI 등이 위치하며 인터페이스의 구체적인 구현체(Implementation)를 제공함.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

비교 항목계층형 아키텍처 (Traditional)어니언 아키텍처 (Onion)
중심점데이터베이스 (Database Centric)도메인 모델 (Domain Centric)
의존성상위 -> 하위 (DB가 최하위)외부 -> 내부 (Core가 중심)
인프라 결합하위 계층에 강결합됨인터페이스를 통한 느슨한 결합
유연성기술 스택 변경 시 로직 수정 필요기술 스택 변경이 용이함

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

  • 판단 지표: 도메인이 복잡하고 빈번한 비즈니스 로직 변경이 예상될 때, 그리고 다양한 인프라(다중 DB, 다양한 API)를 연동해야 할 때 적합함.
  • 적용 전략: 도메인 계층에는 어떠한 외부 라이브러리나 기술적 의존성도 침투하지 못하도록 **순수(Plain)**하게 유지하는 것이 핵심 성공 요인임.

Ⅴ. 기대효과 및 결론 (Future & Standard)

  • 기술적 변화(Legacy 교체, 클라우드 이전 등)에 관계없이 비즈니스 가치를 안정적으로 유지할 수 있는 지속 가능한 아키텍처를 제공함.
  • DDD(Domain-Driven Design)의 전술적 설계 요소들과 완벽하게 부합하며, 현대 소프트웨어 엔지니어링의 표준 구조로 자리 잡음.

📌 관련 개념 맵 (Knowledge Graph)

  • 상위 개념: 소프트웨어 아키텍처, 의존성 역전 원칙 (DIP)
  • 동급 개념: 클린 아키텍처, 헥사고날 아키텍처
  • 하위 개념: 도메인 모델, 엔티티, 인터페이스

👶 어린이를 위한 3줄 비유 설명

  • 축구팀에서 가장 중요한 건 '선수들'이지 '경기장'이 아니에요.
  • 경기장이 잔디든 인조잔디든 상관없이 선수들은 축구 실력을 발휘할 수 있어야 해요.
  • 선수를 가장 중심에 두고 경기장이나 축구공은 나중에 고르는 것과 같은 원리에요.