• 한 헥사곤의 코어 내부에서 구현체 -> <<인터페이스>>가 보인다면, 그 인터페이스는 구현체가 필요로 하는 협력자일 가능성이 크다. 이 경우 그 인터페이스는 대체로 출력 포트이고, 구현체는 유즈케이스 또는 애플리케이션 서비스다. 즉, “이 기능이 필요하니 바깥에서 누군가 구현해 달라”는 의미에 가깝다.
• 한 헥사곤의 코어 내부에서 구현체 -|> <<인터페이스>>가 보인다면, 그 인터페이스는 구현체가 외부에 제공하는 유즈케이스 계약일 가능성이 크다. 이 경우 그 인터페이스는 대체로 입력 포트이고, 구현체는 유즈케이스 또는 애플리케이션 서비스다. 즉, “이 유즈케이스는 이 계약으로 호출할 수 있다”는 의미에 가깝다.
• 한 헥사곤에서 바깥 계층의 구현체가 안쪽 계층의 <<인터페이스>>를 |>로 구현한다면, 그 인터페이스는 대체로 출력 포트이고 구현체는 어댑터다. 즉, 코어가 필요로 하는 협력을 외부 기술 요소가 구체화한 형태다.
• 서로 다른 헥사곤을 연결할 때는 Hexagon A의 출력 포트를 구현하는 어댑터 -> Hexagon B의 입력 포트 같은 브리지 형태가 자주 나타난다. 이 경우 브리지 구현체는 양쪽 계약을 모두 알게 되므로, 각 헥사곤의 내부 도메인 타입이 상대 헥사곤에 직접 새지 않도록 전용 contract 타입이나 DTO를 두고 변환하는 편이 안전하다. 다만 이것이 항상 필수는 아니다. 같은 bounded context 안에서 동일 모델을 의도적으로 공유하는 경우라면 공통 타입을 쓰는 선택도 가능하다. 그래도 기본값은 분리와 매핑 쪽이 더 안전하다.

parse me : 언젠가 이 메모에 쓰이면 좋을 것 같은 재료들입니다.

1. 클린 아키텍처를 유지하며 Python/FastAPI 코드 작성을 LLM에게 위임하기 위한 프롬프트

from : 이 메모에 쓰인 생각을 만든 과거의 생각들과 연관관계를 설명합니다.

1. 인프라 레이어(Gateway또는 Repository)를 다룰 때에는 포트와 어답터를 떠올리면 쉽다. 포트가 규격 구멍이다. 이 규격에 맞춰 구현하면 어댑터다.
   • 앞의 글은 출력 포트(repository의 도메인 계층 인터페이스와 인프라 계층 구현체)의 관계를 설명한다.
   • 한편 이 글은 레이어와 입출력 포트의 종류를 가리지 않는 더 일반적인 패턴을 설명한다.
2. 작은 규모에서는 유즈케이스의 인터페이스를 만들지 마라.
   • 앞의 글은 FastAPI/CLI/메시지 컨슈머 같은 진입부를 어떻게 볼지 설명하고 있다.
   • 한편 이 글은 이 인터페이스가 input port인가, output port인가”를 판별하는 더 일반적인 규칙을 설명한다.
3. a0_4.1_1.1. title: 클래스 다이어그램의 상속관계 기호는 이해했지만 연관관계 기호들이 이해되지 않는다면, 모든 것을 지우고 의존과 연관 기호의 의미를 먼저 이해해야 한다. 본질은 화살표, 밀함(dense), 소함(sparse)이다.
   • 소프트웨어를 추상적으로 바라보려고 할 때 “다이어그램을 보면 어떨까” 하는 생각이 들곤 한다. 다이어그램에서 가장 먼저 파악하고 싶은 것은 계층 구조다. 하지만 상속과 의존이 난무하는 다이어그램을 봐도 어디가 계층 경계인지, 어떻게 해석해야 하는지 막막한 경우가 많았다.
   • 이 글에서는 다이어그램 기호(상속, 의존)와 포트-어댑터가 사용된 CA 계층의 관계에 대해 설명한다.

supplementary : 이 메모에 작성된 생각을 뒷받침하는 새로운 메모입니다.

1. None

opposite : 이 메모에 작성된 생각과 대조되는 새로운 메모입니다.

1. None

to : 이 메모에 작성된 생각으로부터 발전된 생각의 메모입니다.