메신저 프로젝트

설계

목적

• Clean Architecture + DDD 패턴

핵심 원칙

1. 의존성 방향: 항상 외부(infrastructure) → 내부(domain) 방향
2. 단일 책임: 각 컴포넌트는 하나의 명확한 책임만
3. 레이어 분리: 각 레이어는 자신보다 안쪽 레이어만 의존

---

최종 설계 구조

1. 레이어 구조

┌─────────────────────────────────────┐
│  Presentation Layer (Controller)    │  ← 사용자 인터페이스
├─────────────────────────────────────┤
│  Application Layer (Service)        │  ← 유스케이스 조율
├─────────────────────────────────────┤
│  Domain Layer (Entity, Service)     │  ← 비즈니스 로직 핵심
├─────────────────────────────────────┤
│  Infrastructure Layer (Repo, API)   │  ← 기술적 세부사항
└─────────────────────────────────────┘

의존성 방향:

Controller → Application Service → Domain Service → Entity
                ↓                      ↓
          Infrastructure ←──────────────┘
          (Repository, Sender)

서비스 기능 추가 시 설계 고민

예약 시간 이후에 추가된 유저도 전송 대상으로 포함 되도록 수정