왜 필요한가

독자가 웹과 명령줄에서 유용한 글을 저장하는 예산 안내를 만든다고 가정해 봅시다. 화면과 저장소가 바뀌어도 저장 규칙은 그대로여야 합니다. 제작팀은 직접 의존보다 안쪽의 사용 사례 중심을 택합니다.

어떻게 해결하는가

  1. 가상 단일 프로세스: 하나, 가계부 안내 미저장. HTTP·CLI 컨트롤러가 ID를 SaveArticle에 전달하고 SavedArticle이 검증합니다.
  2. SaveArticle은 메모리·내장 데이터베이스 어댑터가 구현한 SaveRepository를 호출합니다. 소스 참조는 어댑터 → 유스케이스 계약 → 도메인으로, 호출은 바깥 저장소로 향합니다. 경계에는 단순 데이터만 전달하며 ORM 행은 밖에 둡니다.
  3. 저장 완료: 0 → 1건, 반복해도 1건. 빈 ID나 쓰기 전 실패는 0건 유지, 문제 수정 후 재시도.
의존 방향과 호출 방향은 다릅니다

설명을 위한 가상 예시

의존성은 정책을 향해

하나가 가계부 안내를 저장하려 함 · 처음에는 미저장

단일 프로세스 · 점선 테두리

1 · 프레임워크·드라이버

HTTP / CLI · 메모리 / 내장 데이터베이스

↓ 소스 의존성

2 · 어댑터

컨트롤러는 ID 변환 · 저장 어댑터는 레코드 변환

↓ 소스 의존성

3 · 애플리케이션 정책

SaveArticle

SaveRepository 인터페이스 소유

↓ 소스 의존성

4 · 도메인 정책

SavedArticle

빈 독자·문서 ID 거부

저장 경계에서

← 소스 의존성SaveRepository (안쪽) ← 저장 어댑터

실행 중 호출 →SaveArticle → SaveRepository 경유 → 저장 어댑터 (바깥)

경계에는 단순 ID·저장 완료 결과만 전달. ORM 행은 바깥에 유지. 네 영역은 예시이며 필수 폴더 구조가 아닙니다.

  • 저장 → 반복: 0 → 1 → 1건. 저장 완료 반환.
  • 빈 저장소에서: 빈 ID나 쓰기 전 실패 → 0건. 문제 수정 후 재시도.

HTTP·CLI와 메모리·내장 데이터베이스는 대안입니다. 데이터 이전을 뜻하지 않습니다.

네 정책 영역은 하나의 프로세스를 공유합니다. 안쪽 소스 의존성이 독립 배포나 장애 격리를 만들지는 않습니다.

무엇이라 부르는가

클린 아키텍처는 소스 의존성을 정책 쪽으로 향하게 합니다. 실행 중 호출은 안쪽 소유 인터페이스를 통해 바깥으로 나갈 수 있습니다. Martin

헥사고날 포트와 결합할 수 있습니다. 폴더 네 개가 필수는 아닙니다.

경계의 데이터 변환은 관리 비용이 듭니다.