DDD Boundary

도메인 경계는 폴더명이 아니라 규칙이 새는 지점으로 나눈다

DDD에서 중요한 것은 module 이름이 아니라 불변식, 언어, 저장소 의존성이 어디에서 보호되는지다. 도메인 규칙이 외부 모양에 끌려가면 경계가 실패한 것이다.

Interface Controller / DTO

HTTP, 인증, 입력 형식을 command로 번역한다.

Application Use case / Port

흐름과 트랜잭션을 조율하고 도메인 규칙 판단은 넘긴다.

Domain Aggregate / Event

상태 전이, 불변식, 업무 언어를 직접 지킨다.

Infrastructure Repository Adapter

Prisma, TypeORM, 외부 API 모양을 contract 뒤에 숨긴다.

판정 축	A급 신호	경계 실패 신호	수정 방향
언어ubiquitous language	command, event 이름이 업무 표현과 일치	같은 “취소”가 주문/결제/정산에서 섞임	bounded context를 나누고 용어를 고정
규칙aggregate invariant	aggregate method가 상태 전이를 검증	service if문이 모든 규칙을 직접 조립	규칙을 domain method와 event로 이동
의존성repository contract	domain 테스트가 DB adapter 없이 가능	ORM entity 컬럼 변경이 domain을 깨뜨림	port와 mapper로 외부 shape 차단

나쁜 경계 폴더는 많지만 도메인은 얇다

Controller DTO, Prisma model, 외부 API 응답이 aggregate까지 들어오면 domain layer는 이름뿐이고 변경 비용은 그대로 남는다.

test adapter 없이 규칙을 테스트할 수 있는가

가능하면 도메인 경계가 저장소 세부사항을 막고 있다.

event 이벤트 이름만 보고 정책 변화를 설명할 수 있는가

설명되지 않으면 로그와 도메인 이벤트가 섞인 것이다.

기준: NestJS에서 DDD를 적용한다는 말은 계층을 많이 만드는 것이 아니라, 도메인 규칙이 controller, ORM, 외부 API 모양에 오염되지 않도록 책임 경계를 고정한다는 뜻이다.