왜 필요한가

업무 규칙은 데이터베이스나 화면이 바뀌어도 유지되어야 합니다. 세부 기술에 직접 의존하면 기술 교체가 규칙 변경으로 번집니다.

어떻게 해결하는가

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

설명을 위한 가상 예시

의존성은 정책을 향해

R1 · A17 · 처음에는 미저장

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

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

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

↓ 소스 의존성

2 · 어댑터

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

↓ 소스 의존성

3 · 애플리케이션 정책

SaveArticle

SaveRepository 인터페이스 소유

↓ 소스 의존성

4 · 도메인 정책

SavedArticle

빈 독자·문서 ID 거부

저장 경계에서

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

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

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

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

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

무엇이라 부르는가

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

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

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