인증, 입력 검증, HTTP 모양을 다루고 command로 변환한다.
NestJS DDD
도메인 경계는 폴더 이름이 아니라 규칙이 새는 지점으로 나눈다
bounded context는 module 이름을 예쁘게 나누는 일이 아니다. aggregate가 지키는 불변식, use case가 여는 명령, repository contract가 숨기는 저장소 세부사항을 기준으로 NestJS 경계를 잡는다.
경계 지도
controller to domain트랜잭션 경계와 호출 순서를 정하고 domain contract에만 의존한다.
주문 취소 가능 여부처럼 비즈니스 규칙을 직접 판정한다.
저장소, 외부 API, ORM 모양은 contract 뒤에 숨긴다.
NestJS 계층 책임
module boundary
프로토콜과 인증 컨텍스트를 command로 변환
HTTP status, guard, DTO shape는 여기서 끝낸다.
orders.controller
트랜잭션과 호출 순서를 조율
도메인 규칙을 대신 판단하지 않고 aggregate에 묻는다.
cancel-order.usecase
상태 전이와 불변식을 직접 보호
배송 시작 후 취소 불가 같은 규칙이 aggregate에
남는다.
Order.cancel()
contract를 DB/API 세부 구현으로 연결
Prisma, TypeORM, 외부 결제 API 의존은 여기서
격리한다.
order.repo.prisma
경계 계약
contract test
검증 질문
DDD 적용 여부는 폴더명보다 규칙, 언어, 의존 방향이 증명한다.
- controller나 ORM entity를 보지 않고 aggregate 규칙을 테스트할 수 있는가?
- repository contract 누락 시 domain 테스트가 아니라 adapter 테스트만 깨지는가?
- domain event 이름만 봐도 어떤 정책 변화가 일어났는지 설명되는가?