nika-blog

🏗 도메인 주도 설계(DDD) - 파트1 동작하는 도메인 모델 만들기 본문

카테고리 없음

🏗 도메인 주도 설계(DDD) - 파트1 동작하는 도메인 모델 만들기

nika0 2025. 2. 16. 15:16

이 포스팅은 https://edu.nextstep.camp/s/yShtEl3D '도메인 주도 설계의 사실과 오해 8기' 강의를 듣고 내 언어로 정리한 포스팅이다. 

 

DDD 강의를 듣게 된 이유는 아는 개발자분의 추천이 있었기 때문인데, 협업에 적용을 원하는 경우는 아니었고 기술적 대화를 할 때 해당 주제가 나온다면 어떤 것인지 이해하고 각 상황에 도입이 필요할지 아닐지를 판단하는 사고를 키우고 싶었기 때문이다. 

🚀 OOP와 DDD의 차이점

🎯 OOP (객체 지향 프로그래밍)

  • 요구사항을 해결하기 위해 코드의 배치를 결정하는 방식
  • 유지보수를 쉽게 하기 위해 SOLID 원칙, 응집도 & 결합도, 의존성 통제, 사이드 이펙트 최소화 등을 고려
  • 프로그래밍을 어떻게 설계하고 구조화할 것인지에 대한 접근 방식

🎯 DDD (도메인 주도 설계)

  • 기술이 아닌 도메인 관점에서 사고하는 방법론
  • 디자인 패턴, 리팩토링, 아키텍처 등의 의사결정을 도메인 중심으로 진행
  • DDD는 프로세스, 방법론, 아키텍처가 아니다!
  • OOP와 DDD는 다른 개념 → OOP는 코드 구조를 고민하는 방식이고, DDD는 도메인 중심으로 설계를 고민하는 철학

📖 Domain-Driven Design (DDD) 책을 이해하는 방법

📌 Eric Evans의 DDD 책이 난해하고 추상적으로 느껴지는 이유?

  • 어떤 상황에도 적합한 특정한 방법이 없기 때문
  • 구체적인 해결 방법을 제시하지 않고 개념적인 접근을 강조

🔄 20년간 변화한 DDD (2004~2024)

1990~2000년대

  • 애자일 등장
  • 객체 지향 프로그래밍이 실무에 적용되기 시작
  • 이와 함께 복잡한 도메인을 효과적으로 모델링하기 위한 DDD 등장

현재 DDD는?

  • 클린 아키텍처, 마이크로서비스 등과 결합되어 더 구체적인 형태로 발전
  • 단순 개념이 아니라 실질적인 아키텍처와 구현 패턴과 연계됨

🏗 [파트 1] 동작하는 도메인 모델 만들기

📌 1. 도메인 모델이란?

🔹 도메인 (Domain)

  • 우리가 해결하려는 문제 영역
  • 예) 음식 배달 서비스
    • 도메인: 메뉴, 주문, 조리, 배달, 결제, 식사
    • 불편한 점을 해결하거나 더 편하게 만들기 위한 것 → SW의 목적
  • 소프트웨어가 다룰 영역(범위) 결정
    • 예) 메뉴, 주문, 결제 기능을 SW로 해결한다고 결정 → 이게 도메인

🔹 모델 (Model)

  • 당면한 문제를 해결하는 데 필요한 것만 포함하고 불필요한 것은 제외
  • 즉, 복잡한 현실을 단순화한 것

🔹 도메인 모델 (Domain Model)

  • 사용자가 SW를 사용하는 영역 안에서 문제를 해결하는 데 필요한 요소만 포함한 것
  • 비즈니스 로직을 표현하며, 개발자가 도메인 전문가와 소통할 수 있도록 설계된 모델

📌 2. ‘동작하는’ 도메인 모델이란?

과거에는 도메인 모델, 설계 모델, 구현 모델이 따로 존재했음

  • 도메인 모델: 이론적인 비즈니스 개념
  • 설계 모델: 도메인 모델을 기반으로 한 소프트웨어 설계
  • 구현 모델: 설계를 코드로 변환

💡 하지만 DDD에서는 도메인 모델이 직접 구현까지 이어짐

  • 설계와 구현이 분리되지 않고 하나로 연결
  • 변경이 발생하면 설계와 코드가 서로 피드백을 주고받음

📌 3. 도메인 모델을 ‘만드는’ 과정

🔹 1) 지식 탐구

  • 도메인 전문가와 개발팀이 협력하여 도메인을 깊이 이해
  • 불필요한 개념을 제거하고, 핵심적인 개념만 남기도록 모델 단순화

🔹 2) 유비쿼터스 언어 (Ubiquitous Language)

  • 도메인 전문가와 개발자가 동일한 용어를 사용하도록 정리
  • 사업적 언어를 기술적 언어로 변환할 필요 없이 같은 단어를 사용
  • 즉, 개발 용어와 사업적 용어의 교집합을 찾는 과정

🔹 3) 도메인 모델 = 코드

  • 도메인 모델과 코드가 일치해야 함
  • 즉, 코드의 변경 = 비즈니스 로직의 변경
  • 개발자가 코드만 봐도 비즈니스 로직을 쉽게 이해할 수 있도록 설계

🏆 마무리: DDD를 적용하면?

✅ 기술이 아니라 비즈니스 도메인 중심으로 사고
✅ 도메인 전문가와 개발자가 같은 언어를 사용하여 커뮤니케이션 개선
✅ 비즈니스 로직과 코드가 일치하여 유지보수성이 높아짐
✅ 설계와 구현이 연결되어 피드백이 원활해짐

Eric Evans의 DDD는 단순한 개발 방식이 아니라, 도메인을 중심으로 문제를 해결하는 사고 방식입니다. DDD를 적용하면 소프트웨어의 본질적인 목표인 "비즈니스 문제 해결"에 더 집중할 수 있게 됩니다. 🚀