에릭 에반스의 ‘도메인 주도 설계’ 책과 조영호의 ‘도메인 주도 설계의 사실과 오해’ 강의를 기반으로 이해한 내용을 작성해보려고 합니다.
도메인 모델에 대해 알아봅시다.

도메인 주도 설계 1편

도메인 주도 설계란?

도메인 주도 설계란 무엇일까? 이에 대해 말하기 전에 소프트웨어란 무엇일까요?

’ 그 소프트웨어의 사용자를 위해 도메인에 관련된 문제를 해결하는 능력에 있다. ‘

개발 이라고 한다면, 기술적인 부분에 포커스를 두고 하지만 DDD 도메인 주도 설계는 사용자의 문제를 해결하는데 중점을 둡니다.

도메인 주도 설계의 핵심은 복잡한 도메인을 다뤄야 하는 소프트웨어 프로젝트에 박차를 가하는 것을 목표로 삼는 사고방식이자 우선순위의 모음이다. 이 말의 뜻은 요즘 DDD가 방법론이다 라고들 하지만 방법론 보다는 패턴들의 집합체라고 생각된다. 00이런 상황에서는 이 패턴을 사용하면 좋아요 ~ 00패턴으로 짜면 단순해져요 ~

모든 사람이 이야기 하지만 어느 누구도 제대로 이해하지 못한 책 - 에릭 에반스

그 제대로 이해하지 못한 책에 대해서 한번 이야기 해보려고 합니다.

” 도메인 “ 이란 ?

• 사용자가 프로그램을 사용하는 주제 영역
  소프트웨어는 문제를 해결하기 위한 것 or 사용자의 니즈를 충족시키기 위한 것
  여기서 문제의 영역을 분리 해 놓은것이 도메인이다.

예를 들어 아래와 같이 옷을 구매하는 과정이 있을 때 문제의 영역을 분리해 놓은 것이 도메인입니다.
(도메인)[옷 선택 -> 주문 -> 결제] -> 제작 -> 배달 -> 착용

” 모델 “ 이란?

• 당면한 문제를 해결하는 것과 관련된 측면을 추상화하고 단순화시켜 중요하지 않은 세부사항은 생략 하는 것
• 이때 형태나, 형식은 중요하지 않습니다. 무언가를 정하려고 할 때 공감가는 형태로만 구성되면 됩니다.

그래서 도메인 주도 개발에서 말하는 “도메인 모델 “ 이란?

• 사용자가 프로그램을 사용하는 주제 영역 안에서 당면한 문제를 해결하는 것과 관련된 측면을 추상화하고 중요하지 않은 세부사항은 생략 하는 것 이라고 할 수 있습니다.

이 도메인 모델을 실제로 동작시키기 위해서는 추상화된 도메인 모델을 기반으로 핵심을 설계하고, 이를 코드로 구현해야 합니다. 만약 코드에 변경이 발생하면, 도메인 모델과 핵심 설계 또한 함께 변경되어야 합니다.

도메인 모델과 핵심 설계는 서로 상호 작용하며, 반복적인 수정과 변형을 통해 점차 완성됩니다. 즉, 도메인 모델의 변경은 코드의 변경을 유도하고, 반대로 코드의 변경은 도메인 모델의 수정을 필요로 합니다.

도메인 주도 설계의 관점에서 보면, 도메인 모델 자체가 코드라고 할 수 있습니다. 이 말은 코드가 단순히 기능을 실행시키는 도구가 아니라, 업무 도메인을 표현하고 문제를 해결하는 핵심적인 부분임을 의미합니다.

도메인 주도 설계의 맥락에서 도메인 모델은 코드입니다.

도메인 주도 설계(DDD)의 주요 개념과 절차을 이해하기 위해 앞선 내용을 다음과 같이 정리해 보겠습니다 모든 설계 단계에서, 개발자와 도메인 전문가는 함께 나아가며 효과적인 도메인 모델을 창출하고 추상화합니다. 여기서 도메인 전문가는 특정 영역의 지식이 깊은 사람으로, 프로젝트 관계자들 중에서도 문제의 본질을 가장 잘 이해하고 있는 사람을 의미합니다.

(우리가 개발하는 프로젝트의 기획자 또는 사장님 또는 팀장님 등 해당 문제에 대해 가장 잘 아는 사람이 도메인 전문가입니다.)

이런 과정에서 사용되는 언어가 바로 유비쿼터스 언어입니다. 이 언어는 팀 내의 모든 구성원들이 사용하며, 도메인 전문가와 개발자 사이의 의사소통을 돕습니다.

도메인 주도 설계의 전반적인 작업 흐름은 다음과 같습니다

• 도메인 전문가와 개발팀은 함께 도메인 모델을 창조한다.
• 유비쿼터스 언어를 만들어 커뮤니케이션에 활용한다.
• 추상화된 도메인 모델을 유비쿼터스 언어로 용어를 정의한다.
• 그리고 그 기반으로 코드를 구현하는 일을 반복한다.

도메인 계층은 비즈니스 로직의 설계와 구현으로 이루어집니다. 핵심적으로 도메인 로직이 프로그램의 다른 부분과 섞이지 않도록 격리 시키는 것이 도메인 주도 설계에서 중요합니다.

도메인 주도 설계의 장단점

• 도메인 주도 설계의 장점은 어떻게든 만들어도 된다 이고, 단점은 정형화된 아키텍처가 없다는 것입니다.
• 도메인 주도 설계의 가장 큰 장점 중 하나는 소프트웨어가 사용자의 문제를 해결하는데 초점을 맞춘다는 것입니다. 이는 소프트웨어가 진정으로 사용자 중심이 되게 하고, 그 결과 사용자 경험을 개선하고 비즈니스 가치를 높이는 기회를 제공합니다. 또한, 도메인 주도 설계의 유비쿼터스 언어는 도메인 모델과 코드 간의 간극을 줄여줍니다. 이를 통해 개발팀과 도메인 전문가간의 교차 소통이 향상되며, 이해 오류를 방지하고 프로젝트 진행 과정에서 발생할 수 있는 문제를 미리 해결할 수 있게 합니다.

DDD를 설명할 때 아니면 사용할 때 종종 Hexagonal Alchitecture가 사용되는데 그 이유는 기본적으로 헥사고날 아키텍처는 도메인을 분리하여 사용하기 때문입니다. 그러나 “Hexagonal Architecture가 도메인 주도 설계”라는 말은 틀린 말입니다. 이 두 개념은 서로 다른 레벨의 설계 접근 방식을 제시하며, DDD는 도메인 로직을 격리하는 것에 초점을 맞추고 있습니다.