my-backend-architecture

사용자 개인의 백엔드 코드 구조 선호를 정리한 지식 스킬. SKILL.md는 라우팅 테이블 역할만 하고, 실제 내용은 references에 Progressive Disclosure로 분할되어 있다. 사용자 질문 유형에 따라 필요한 파일만 로드해 답한다.

핵심 원칙

1. 기본 레이어 4개: app / domain / infrastructure / shared. 그 사이에 사용자 정의 중간 레이어를 필요할 때만 삽입한다. 이름·개수는 팀이 결정. 빈 레이어는 세금.
2. 의존은 단방향. 상위 레이어의 module(resource)은 하위 레이어의 module만 참조 가능. 역방향 import 전면 금지. 단 infrastructure는 domain 인터페이스를 구현하므로 import 방향이 역전(DIP).
3. app은 resource 단위, 나머지는 module 단위. domain은 프레임워크 의존 없는 순수 코드.
4. 같은 레이어 module 간 참조 금지 (domain·shared 제외). 해결책: 공통 로직을 하위 레이어로 추출하거나, 중간 레이어에 인터페이스를 두고 DIP 적용.
5. 규칙 판정은 domain에, 오케스트레이션·I/O·트랜잭션은 app / 중간 레이어에. Repository는 Application Service에만 주입, Domain Service에는 인자 전달.

의존 다이어그램

app (resource)
  ↓
(사용자 정의 중간 레이어)?   module. 이름 자유. 선택.
  ↓
domain  ◄───────── infrastructure   ← DIP: infrastructure가 domain 인터페이스 구현
(module)           (module)
  ↓                    ↓
shared              ← 모든 레이어가 shared 참조 가능

라우팅 테이블

원칙

• 완벽한 클린 아키텍처 지향 아님. domain이 shared를 참조하는 건 허용. 상세: 08-misc.md.
• NestJS가 주 예시지만 원리는 DI 프레임워크가 있는 환경 전반에 적용 가능.
• 테스트 1순위는 도메인 정책·비즈니스 규칙. 나머지는 선택.
• 이 스킬의 "module"은 폴더 단위 코드 경계. DI 프레임워크의 Module/Component 어노테이션과 다른 개념.