도메인 주도 설계(DDD, Domain-Driven Design)는 소프트웨어의 복잡성을 해결하기 위해 비즈니스 도메인(핵심 비즈니스 규칙과 실세계의 비즈니스 프로세스)을 아키텍처와 설계의 중심에 두는 접근 방식이다. 기술적 세부사항보다는 비즈니스의 본질을 모델링하고, 개발팀과 도메인 전문가가 동일한 언어로 소통하며 시스템을 구축함으로써 요구사항의 오해를 줄이고 소프트웨어의 가치를 극대화하는 것을 목표로 한다.
2. 핵심 체계 (Strategic & Tactical)
전략적 설계 (Strategic Design): 시스템의 거시적인 구조를 결정하는 단계.
Bounded Context: 모델이 유효한 논리적 경계 설정.
Ubiquitous Language: 팀 전체가 공유하는 공통 언어 정의.
Context Mapping: 컨텍스트 간의 관계와 데이터 흐름 정의.
전술적 설계 (Tactical Design): 도메인 모델을 코드로 구현하는 구체적인 패턴.
Aggregates: 데이터 무결성을 보장하는 객체들의 군집.
Entities & Value Objects: 식별성 유무에 따른 객체 분류.
Repositories & Services: 데이터 영속성 처리 및 도메인 로직 오케스트레이션.
Domain Events: 시스템 상태 변화를 알리는 비동기 신호.
3. 엔지니어링 가치
비즈니스 정렬성: 소프트웨어 구조가 실제 비즈니스 프로세스와 일치하므로, 비즈니스의 변화가 시스템의 변경으로 정확하고 신속하게 전이됨.
복잡성 제어: 거대한 모놀리식 시스템을 명확한 경계(Bounded Context)를 가진 독립적인 모듈들로 분해하여 인지 부하를 줄이고 관리 효율성을 높임.
테스트 및 유지보수 용이성: 핵심 도메인 로직이 인프라스트럭처나 UI와 격리되어 있어, 핵심 비즈니스 규칙에 대한 정밀한 테스트와 안전한 리팩토링이 가능.
4. 트레이드오프 및 주의사항
높은 초기 학습 곡선: DDD의 방대한 용어와 철학을 이해하고 숙련되는 데 많은 시간과 노력이 필요함.
도메인 전문가의 참여 필수: 기술진만으로는 DDD를 성공시킬 수 없으며, 비즈니스 지식을 가진 전문가의 적극적이고 지속적인 참여가 필수적임.
오버엔지니어링 경계: 비즈니스 로직이 단순한 경우에는 오히려 과도한 추상화와 계층 분리로 인해 개발 속도만 늦출 수 있으므로, 도메인의 복잡도에 따른 선별적 도입이 중요함.
Antigravity Agent