도메인 주도 설계의 모델링과 구현 기법

도메인 모델이 코드의 중심이 되도록

객체지향 언어를 사용해도 구현이 트랜잭션 스크립트와 데이터 중심 코드로 흘러가면, 비즈니스 규칙은 코드 밖의 문서와 사람의 머릿속에 남는다. 도메인 주도 설계(DDD, Domain Driven Design)는 특정 도메인의 요구 정의와 분석 기법, 방법론, 절차를 체계화해 이 간극을 줄이는 개발 방식이다.

핵심은 기술 구현보다 비즈니스 도메인의 본질을 모델링하고, 그 모델을 코드와 맞추는 데 있다. 도메인 전문가가 사용하는 언어를 코드에 반영하면 명세와 구현의 차이를 줄일 수 있다. 복잡한 시스템에서는 바운디드 컨텍스트(Bounded Context)로 비즈니스 로직을 격리해 관리한다.

모델을 나누고 공통 영역을 다루는 방식

DDD의 모델은 도메인을 한 장의 설계도로 고정하기보다, 목적과 범위에 맞춰 나눈다.

구분	설명	주요 역할
Main Model	사용자 관점에서 정의된 도메인 영역 모델	도메인 전체의 비즈니스 가치와 흐름을 정의
Sub Model	메인 모델의 특정 부분을 상세화한 개발 모델	구체적인 데이터 구조와 행위를 정의하는 상세 설계도
Shared Kernel	두 개 이상의 컨텍스트가 공유하는 공통 도메인 모델	AOP의 Cross-cutting 관심사처럼 여러 영역에 걸친 공통 요소

Main Model은 도메인 전체의 비즈니스 가치와 흐름을 다루고, Sub Model은 그 안의 특정 영역을 상세화한다. Shared Kernel은 여러 컨텍스트가 함께 써야 하는 공통 도메인 모델이다.

같은 언어로 요구사항과 구현을 연결하기

보편적 언어(Ubiquitous Language)는 프로젝트 구성원이 공통으로 사용하는 용어 체계다. 도메인 전문가와 개발자가 같은 개념을 같은 말로 다루도록 하며, SOA나 UML 모델링 과정에서도 일관성을 유지하는 기준이 된다.

용어 사전(Glossary)은 그 언어를 정의한 어휘집(Vocabulary)이다. 개념마다 단일한 의미를 부여해 해석의 모호성을 줄인다.

모델을 구현으로 옮기는 기술

DDD는 모델링만으로 끝나지 않는다. 모델의 순수성을 지키면서 기술적 복잡성을 처리하기 위해 AOP, DI/IoC, 디자인 패턴, UML 모델링을 함께 활용한다.

⤢✕

AOP(Aspect Oriented Programming)는 트랜잭션 처리, 보안, 로깅처럼 비즈니스 로직과 분리되는 횡단 관심사를 Shared Kernel 형태로 관리한다.

DI/IoC(Dependency Injection / Inversion of Control)는 객체 간 강한 결합을 줄이는 데 쓰인다. 컨테이너가 종속 구조를 주입하면 도메인 객체가 특정 기술 인프라에 직접 종속되는 것을 피할 수 있다.

팩토리(Factory), 리포지토리(Repository), 전략(Strategy) 패턴은 도메인 모델의 생명주기와 행위를 표준화된 방식으로 구현하는 데 활용한다. UML 모델링은 보편적 언어를 시각화하고 복잡한 도메인 관계를 명확히 규정하는 도구가 된다.

컨텍스트부터 식별하고 내부 모델을 구체화하기

전략적 설계(Strategic Design)는 비즈니스 도메인을 분석해 바운디드 컨텍스트를 식별하고 컨텍스트 맵을 만드는 과정이다. 이때 보편적 언어를 확립하고 팀 간 인터페이스 규칙을 정한다.

전술적 설계(Tactical Design)는 식별된 바운디드 컨텍스트 내부를 구체화한다. 엔티티(Entity), 값 객체(Value Object), 애그리거트(Aggregate)를 이용해 도메인의 제약사항을 코드로 엄격하게 표현한다.

DDD를 적용하면 요구사항 변경에 도메인 모델을 중심으로 대응할 수 있고, 기술 인프라와 비즈니스 로직의 분리로 코드 이해와 관리가 쉬워진다. 도메인에 대한 깊은 이해를 설계에 반영해 결함을 줄이고 확장성을 높이는 방향으로 이어진다.