도메인 개발

[1210thatman]

Summary

Hexagonal Architecture에서 도메인 레이어를 DDD 기준으로 설계하고,
각 도메인별로 엔티티/값객체/애그리게잇/도메인서비스/도메인이벤트/리포지토리 포트의 최소 골격을 구현한다.

Problem / Motivation

• 현재 “도메인 규칙(불변조건, 상태전이, 정책)”이 코드 상에서 흩어질 위험이 있음
• Hexagonal 구조에서 도메인이 프레임워크/DB/외부 API 의존 없이 독립적으로 진화할 수 있도록 경계와 규칙을 먼저 고정할 필요가 있음
• 도메인별 패키지/모듈 표준이 없으면 이후 기능 개발 시 구조가 빠르게 붕괴함

Proposed Solution

도메인 레이어 설계 원칙

1. 도메인 레이어는 프레임워크/인프라 의존 금지
2. 도메인 로직은 가능한 한 애그리게잇 내부에 위치(불변조건/상태전이 포함)
3. 외부 의존이 필요한 경우 Port(인터페이스) 로만 노출(Repository, Outbound Service 등)
4. 트랜잭션/유스케이스 흐름은 애플리케이션 계층 책임(이번 범위 제외)

Scope

도메인 레이어(모델/규칙/Port/이벤트) 설계 및 기본 구현
도메인 단위 테스트

Dependencies / Risks

1. 도메인 경계가 불명확하면 애그리게잇 설계가 흔들릴 수 있음 → 최소한 “도메인별 책임/용어(ubiquitous language)” 짧게라도 합의 필요
2. 이벤트/정책이 과설계될 수 있음 → 이번 범위는 “최소 골격 + 필수 규칙”에 한정

Additional Notes

1. 도메인 레이어가 프레임워크/인프라 의존 없이 컴파일 및 테스트 통과
2. 핵심 상태전이/불변조건이 테스트로 고정되어 회귀 방지
3. 도메인 간 참조가 필요할 경우, 직접 참조 대신 명시적 계약(VO/ID/Port/Domain Event) 으로만 연결(순환 의존 없음)
4. 패키지/모듈 구조가 표준에 맞게 정리되어 신규 기능이 같은 규칙으로 확장 가능