본문 바로가기
CS 지식/아키텍처

도메인 주도 설계(Domain Driven Design)란?

by 검은도자기 2022. 9. 22.

정의

비즈니스 도메인(Business Domain)을 중심으로 소프트웨어를 설계하고 개발하는 개발 방법론

 

 

비즈니스 도메인이란?

회사가 고객에게 제공하는 서비스를 의미합니다. (예: 아마존 - 클라우드 서비스)

 

 

왜 도메인 주도 설계가 나왔을까?

과거부터 현재까지 효과적인 소프트웨어 엔지니어링을 위해 다양한 설계 방법들이 등장했습니다. 하지만 다양한 개발 방법들이 등장함에도 불구하고 프로젝트는 여전히 종종 실패를 합니다. 프로젝트가 실패하는 이유를 찾아보면 여러 가지 이유가 있겠지만 주로 공통적으로 말하는 실패 요인은 커뮤니케이션입니다. 이러한 커뮤니케이션 문제를 해결하기 위해 등장하지 않았나 생각합니다.

 

 

어떻게 설계를 할까?

도메인 주도 설계 방식은 크게 전략적 설계와 전술적 설계로 나뉩니다.

 

1. 전략적 설계

  • 무엇? 과 왜?라는 질문을 중심으로 어떤 소프트웨어를 만드는지에 대한 해답을 찾아가는 과정입니다.
  • 여기서는 다음과 같은 과정으로 해답을 찾습니다.
  1. 도메인 전문가 및 기술팀이 함께 모여 도메인에 대한 지식 공유 및 이해를 한 다음 이를 기반으로 유비쿼터스 언어(Ubiquitous Language)를 정의합니다.
  2. 정의한 유비쿼터스 언어들을 여러 개로 나눈 다음 도메인(예: 주문, 결제)에 어울리는 언어별로 분류하여 도메인 모델(Domain Model)을 정의합니다.
  3. 유비쿼터스 언어를 사용했을 때, 해당 용어의 개념이 달리지는 곳을 기준으로 바운디드 컨텍스트(bounded context)를 나눕니다.
  4. 바운디드 컨텍스트(bounded context) 간의 관계를 컨텍스트 맵(context map)으로 표현합니다.

 

2. 전술적 설계

  • 어떻게?라는 질문을 중심으로 어떻게 개발할 것인지에 대한 방법을 찾는 과정입니다.
  • 전략적 설계에서 도출된 바운디드 컨텍스트(bounded context)와 도메인을 이용하여 어떤 방식으로 개발할지 정의합니다.

 

 

용어 정리

  • 유비쿼터스 언어(Ubiquitous Language) : 비즈니스 전문가, 관계자, 개발자가 같은 것을 생각할 수 있도록 명확하게 정의한 비즈니스 용어
  • 도메인 모델(Domain Model) : 복잡한 시스템을 이해하는데 도움을 주기 위해 특정 도메인을 개념적으로 구조화하여 표현한 것
  • 바운디드 컨텍스트(Bounded Context) : 도메인 영역의 경계를 의미하며, 도메인 영역의 경계 내에서는 유비쿼터스 언어의 일관성이 유지됩니다.
  • 컨텍스트 맵(Context Map) : 컨텍스트 경계를 식별해 내고 이들 간의 관계를 표현한 그림

 

 

장점

  • 외부 프레임워크, 기술, 데이터베이스 등에 독립적이며, 프레임워크 및 외부 리소스는 훨씬 적은 노력으로 연결/분리할 수 있습니다.
  • 쉽게 테스트 가능하고 확장 가능합니다.
  • 엔지니어링 팀이 서비스를 더 쉽게 이해할 수 있습니다.

 

 

단점

  • 학습 난이도가 높습니다.
  • DDD 원칙을 지키기 위해 구현해야 할 코드와 개발 복잡성이 증가합니다.
  • 도메인에 대한 표준과 규칙을 정하고 개발해야 하기 때문에 개발 시간이 오래 걸립니다.

 

 

언제 도메인 주도 설계 방식을 사용하면 좋을까?

이 질문에 대해서는 여러 가지 의견이 있을 거라 생각이 됩니다. 도메인 주도 설계 방식을 공부하면서 개인 프로젝트를 만들어 봤을 때 든 생각을 기반으로 다음과 같은 경우에 사용하면 좋지 않을까 생각이 듭니다.

 

  1. 프로젝트 개발 기간이 어느 정도 여유가 있을 경우
  2. 프로젝트가 제공하는 서비스가 복잡할 경우 
  3. 처음부터 구조를 탄탄하게 잡아서 추후에 비즈니스 변경 및 유지보수 시 편하게 개발하고 싶을 경우 

1번의 경우는 도메인 주도 설계 방식의 학습 난이도와 많은 커뮤니케이션으로 인하여 개발 시간이 많이 들었기 때문에 선정하였습니다. 2번의 경우는 프로젝트가 제공하는 서비스가 단순하다면 굳이 많은 시간과 노력을 들여서 DDD를 적용할 필요가 없다 생각이 들어 선정하였으며, 마지막 3번의 경우는 처음 구현 시 시간은 좀 걸렸지만 추후에 기능 변경에 대한 작업 시간이 MVC 방식에 비하여 기능 수정을 쉽게 했기 때문에 선정을 했습니다. (참고로 비즈니스가 복잡할 경우입니다.)

 

 

마무리

오늘은 도메인 주도 설계에 대하여 공부한 내용을 정리해보았습니다. 여러 자료들과 책들을 보면서 공부를 해보니 어떻게 구현해야 하는지 큰 틀은 잡혔으나 각 자료마다 말하고자 하는 의미가 달랐기도 했고 아직 다 이해가 안 되었기 때문에 디테일하게 어떻게 구현해야 할지 아직 감이 안 잡혀서 아쉬울 따름입니다. 현재 이해 못 한 부분들은 추후 심화 버전으로 정리할까 합니다.

아직 부족하거나 틀린 부분이 있을 수도 있으니 주의하시면 좋을 거 같습니다.

이번 포스팅은 마무리하면서 다음 포스팅에서 뵙겠습니다.

 

 

참고

Domain-driven design

도메인 주도 설계 철저 입문

도메인 주도 설계 첫걸음

Domain Driven Design