218. 어니언 아키텍처 (Onion Architecture) - 제프리 팔레르모 도메인 모델 중심 의존성 역전 외부 결합 분리 테스트 용이성 클린 아키텍처 형제

핵심 인사이트: (217번 클린 아키텍처의 쌍둥이 형제) 2008년에 제프리 팔레르모(Jeffrey Palermo)가 헥사고날(216번)을 보고 생각했다. "야 육각형 구조는 너무 추상적이잖아! 우리가 맨날 까먹는 게 뭐야? 바로 DB(데이터)랑 UI(화면)를 핵심 로직이랑 섞어버리는 거잖아! 아예 그림을 동심원 양파(Onion) 모양으로 그려버려! 양파의 제일 안쪽 심지(도메인 모델)에는 자바 코드만 넣고, 양파 껍질을 한 겹씩 깔 때마다 서비스, 인프라를 배치해. 그리고 양파 껍질의 법칙! '바깥 껍질은 안쪽 껍질의 존재를 알지만(의존하지만), 안쪽 껍질은 바깥 껍질이 세상에 존재하는지도 몰라야 한다!!'" 클린 아키텍처(217번)보다 4년 먼저 세상에 나와 '안쪽으로 향하는 의존성'의 시대를 열어젖힌 양파 까기 설계 철학, 어니언 아키텍처다.

Ⅰ. 전통적 계층형(Layered) 구조의 붕괴 (데이터 중심 설계의 저주)

  • 고전적인 3계층(UI ➜ 비즈니스 ➜ DB)의 가장 큰 문제는, 시스템의 뇌(비즈니스)가 가장 바닥에 깔린 인프라(DB)에 의존한다는 것입니다.
  • 결국 뇌(비즈니스)는 엑셀 칸(테이블 구조)에 맞춰서 코드를 짜게 되는 수동적인 바보가 되어버립니다 (데이터 주도 설계의 폐해).

Ⅱ. 어니언 아키텍처 (Onion Architecture)의 개념 🌟

  • 개념: 시스템을 여러 겹의 동심원(양파) 껍질로 구조화하여, 인프라나 UI 같은 껍데기 요소들을 가장 바깥 껍질로 몰아내고, 애플리케이션의 핵심인 '도메인 모델(비즈니스 로직)'을 가장 안쪽 심지에 두어 외부의 변화로부터 100% 격리시키는 아키텍처 패턴입니다.

Ⅲ. 양파를 관통하는 절대 규칙 🌟 핵심 🌟

클린 아키텍처(217번)의 '의존성 규칙'과 소름 돋게 똑같습니다.

의존성은 무조건 안쪽으로만 (Dependency Towards Center)

  • 바깥쪽 껍질의 코드는 안쪽 껍질의 클래스를 Import 해서 쓸 수 있습니다.
  • 하지만 양파 안쪽의 코드는 자기보다 단 1칸이라도 바깥쪽에 있는 껍질의 코드 이름을 절대 부를 수 없습니다! (이름을 적는 순간 컴파일 에러를 내야 함)
  • 효과: 가장 안쪽 심지(도메인) 코드는 바깥에 DB가 있는지, UI가 안드로이드인지 아이폰인지 아예 알 수가 없으므로, 어떤 껍데기를 갈아 끼워도 심지는 평생 재사용됩니다.

Ⅳ. 양파의 4겹 구조 (안쪽에서 바깥쪽으로)

(주의: 217번 클린 아키텍처와 계층 이름만 살짝 다르고 본질은 같습니다.)

  1. 도메인 모델 (Domain Model - 양파 심지): 기업의 핵심 업무 데이터 상태와 행위 (예: 은행의 Account 객체). 순수 언어(Java, C#)로만 짜여져 아무런 의존성이 없습니다.
  2. 도메인 서비스 (Domain Services): 두 개 이상의 도메인 모델이 엮여야 하는 흐름 (예: A계좌에서 B계좌로 이체하기()).
  3. 애플리케이션 서비스 (Application Services): 외부에서 들어온 요청(사용자 클릭)을 받아 도메인 서비스에 일을 시키는 코디네이터 역할입니다.
  4. 인프라스트럭처 / UI / 테스트 (가장 바깥 껍질): 데이터베이스(JPA/Hibernate), 웹 화면(React/Spring MVC), 외부 API 통신 모듈 등 실제 기계와 맞닿는 가장 더러운 기술 껍데기들입니다.

Ⅴ. 의존성 역전 원칙 (DIP)의 마법 🌟 기출 단골 🌟

안쪽 심지(도메인)에서 바깥 껍질(DB)에 데이터를 "저장해!"라고 명령해야 하는데, 안쪽에서는 바깥쪽 놈의 이름을 부를 수 없습니다(의존성 방향 위배). 어떻게 해결할까요?

  • 해결책 (DIP): 안쪽 심지에 저장소_인터페이스(Interface)라는 빈 구멍(명세서)만 뚫어놓습니다. 그리고 바깥 껍질(인프라)에 있는 놈이 이 구멍 규격에 맞춰서 구현체(구현 코드)를 만든 뒤 꽂아줍니다!
  • 안쪽 심지는 바깥놈 이름을 부른 게 아니라, 그냥 자기 방에 뚫린 빈 구멍(인터페이스)에 대고 소리쳤을 뿐인데, 밖에서 구현체가 알아서 작동해 주는 기적(의존성 역전)이 완성됩니다. (216번 헥사고날의 '포트와 어댑터'와 완벽히 동일한 원리)

📢 섹션 요약 비유: **어니언 아키텍처(Onion Architecture)**는 회사를 **'양파 껍질 모양의 보안 등급 구역'**으로 나눈 것과 같습니다. 양파의 가장 안쪽 노란 심지(도메인 모델)는 회사의 **'극비 레시피 연구소'**입니다. 이 연구소 안에는 순수한 연구원(자바 코드)들만 있고, 인터넷이나 전화기(프레임워크)조차 없습니다. 한 꺼풀 바깥 껍질(애플리케이션 서비스)에는 비서들이 있고, 가장 바깥 빨간 껍질(인프라/UI)에는 택배 기사와 홍보팀이 있습니다. 어니언의 절대 법칙은 **'밖에서 안으로 들어가는 단방향 통행'**입니다. 바깥 껍질의 비서나 택배 기사는 안쪽 껍질의 연구소에 서류를 밀어 넣을 수 있지만(의존성 향함), 안쪽 심지의 연구원들은 바깥 껍질에 누가 있는지 이름도 모르고 밖을 내다볼 수도 없습니다. 만약 연구원이 밖으로 우편물을 보내야 한다면 바깥놈 이름을 부르지 않고, 그냥 벽에 뚫린 **'우체통 구멍(인터페이스, DIP)'**에 우편물을 휙 던져놓고 쿨하게 뒤돌아섭니다. 그럼 바깥 껍질의 누군가(인프라 구현체)가 그걸 주워서 알아서 처리해 주는, 핵심 뇌(연구소)를 외부의 더러운 기술로부터 100% 밀봉해버린 아름다운 동심원 아키텍처입니다.