개인 아키텍처 시스템 시리즈
- #1 왜·어떻게 만들었나
- #2 포트 기반 baseline — 지금 이 글
- #3 인프라 concern 조립
- #4 MSA 즉시 접목
이 시스템의 비협상 규칙은 하나다. 모든 패턴은 Clean Architecture + Hexagonal(포트 기반)을 기본 골격으로 삼는다. 언어가 Go든 Java든 Flutter든, 골격은 같다.
1. 한 장으로 보는 골격
Handler → (inbound port) → UseCase → (outbound port) → Repository/Adapter. 제어(흐름)는 오른쪽으로 흐르지만, 의존성은 포트(인터페이스)로 역전시켜 안쪽(UseCase·Domain)이 프레임워크를 전혀 모르게 한다. 이 원리 자체는 지난 Go 아키텍처 시리즈에서 코드로 다뤘다 — 이 글은 그 원리를 여러 언어에 일관되게 강제하는 방식에 대한 이야기다.
2. 같은 개념, 언어별 관용구
| 개념 | Go | Java | Node | React | Flutter |
|---|---|---|---|---|---|
| Handler(구동) | Gin handler | @RestController | express route | hook/컴포넌트 | widget/bloc |
| UseCase | usecase impl | @UseCase | service | use-case hook | usecase |
| Repository(피구동) | GORM repo | JPA repo | prisma repo | api client | repository |
이렇게 Handler/UseCase/Port/Repository라는 같은 개념을 언어별 관용구로 1:1 매핑해 두면, 새 언어를 배우거나 팀을 옮겨도 “이 코드는 어느 자리”인지 헤매지 않는다.
3. 왜 baseline을 하나로 고정했나
- 비교 가능성 — 같은 14-섹션 틀 위에서 언어별 패턴이 나란히 비교된다.
- 교체 용이성 — 프레임워크·ORM은 어댑터라 갈아 끼워도 UseCase는 그대로.
- MSA 준비 — 포트 경계가 이미 그어져 있어, 나중에 서비스로 떼어내기 쉽다(4편).
참고로 MVC를 섞은 스타일도 있지만, 나는 그걸 참조용 카운터-예시로만 두고 베이스라인과 명확히 구분한다. 3편에서는 이 골격 위에 얹는 인프라 자동화를 본다.
답글 남기기