Domain-Driven Design

복잡한 업무 시스템에서는 같은 단어가 팀마다 다른 뜻으로 쓰이기 쉽습니다. 상품팀이 말하는 주문과 정산팀이 말하는 주문의 경계가 다르고, 개발자는 DB 테이블 기준으로 코드를 나누고, 운영자는 배치 흐름 기준으로 문제를 봅니다. 이런 상태에서는 규칙이 중복되고, 어떤 변경이 어느 코드 경계에 속하는지 합의가 안 됩니다. 기술적으로는 동작해도, 모델이 업무 현실을 반영하지 못하면 구조가 계속 흔들립니다.

초기 CRUD 애플리케이션은 화면과 테이블만 잘 맞춰도 어느 정도 버틸 수 있었습니다. 하지만 도메인이 복잡해지고 팀이 커질수록 문제는 저장 기술보다 의미의 충돌에서 더 자주 생겼습니다. 특히 마이크로서비스가 유행하면서 서비스를 어디서 자를지 결정해야 했는데, 기술 계층만으로는 그 경계를 설명할 수 없었습니다. 이 압력 속에서 업무 언어와 경계를 먼저 정리해야 한다는 관점이 설계의 중심으로 올라왔습니다.

보통은 팀이 실제로 쓰는 용어를 정리하는 것부터 시작합니다. 같은 단어가 문맥마다 뜻이 달라지면 하나의 모델 안에 억지로 넣지 않고 Bounded Context를 나눕니다. 각 컨텍스트 안에서는 엔티티, 밸류 객체, 애그리거트 같은 모델 단위를 통해 규칙과 상태 변경을 표현합니다. 애플리케이션 서비스는 그 모델을 호출해 유스케이스를 조율하고, 컨텍스트 바깥과의 연결은 번역 계층이나 이벤트로 다룹니다.

DDD는 Layered Architecture처럼 코드를 몇 층으로 나눌지에 대한 답이 아닙니다. 무엇을 하나의 의미 단위로 보고 어디서 경계를 그을지에 대한 답입니다. Hexagonal Architecture가 외부 기술로부터 코어를 보호하는 방식이라면, DDD는 그 코어 안에 어떤 모델이 있어야 하는지 정하는 방식입니다. 도메인이 단순하고 규칙이 얕은 관리 화면 수준의 시스템이라면 DDD의 개념을 모두 도입하는 비용이 더 클 수 있습니다.

용어 충돌이 자주 발생하거나, 서비스 경계를 나눴는데도 책임이 계속 겹치거나, 규칙이 여러 팀 코드에 중복되어 퍼지는 상황에서 DDD가 힘을 발휘합니다. 특히 결제, 재고, 정산처럼 상태 변화와 규칙의 의미가 중요한 핵심 도메인에서 그렇습니다. 반대로 단순 조회 화면이나 내부 운영 도구처럼 규칙보다 입출력 변환이 중심인 영역은 더 가벼운 모델로도 충분한 경우가 많습니다.