정리하는데 있어서 참으로 오랜 시간이 걸린 것 같다
도메인이란 참으로 추상적인 개념이고 여러 프로젝트를 통해 쌓을 수 밖에 없다고 생각한다
그러다보니 도메인 관련 책을 읽고 여타 글을 읽으면서 나는 도메인을 어떻게 생각하는지,
내가 과연 올바른 도메인 중심 개발을 하고 있는 것인지 의문이 들었다
그리하여 이번 글은 이번 글은 이론을 늘어놓기보단, 나는 DDD를 이렇게 생각했구나 라는 식으로 써 내려갈 것이다
이번 정리를 기점으로 다음 기회에는 더 나은, 좀 더 확고한 개발을 진행할 수 있길 바란다
1. DDD 란?
DDD 란 Domain Driven Development, 즉 도메인을 위주로 개발하자!라는 것이다
개발을 수월하게 진행하기 위해서는 어느 하나를 잡고 그것에 집중하는, 선택과 집중이 중요하다
흔히 이야기 나오는 관심사의 분리, ??? 중심 등이 이것이다
DDD는 그 중심이 도메인이 되는 것이다
그럼 도메인이 뭐길래 그러는거지?
바로 그 부분에 따라 DDD는 다음 2가지로 나눠진다
- 전략적 설계
- 전술적 설계
2. 전략적 설계
앞서 말한 도메인이 뭔데? 라는 의문점을 해소하는 즉, 도메인에 대한 개념을 설계하는 단계이다
1. 도메인이란?
도메인이란 S/W가 사용자에게 제공하는 메인 서비스들로, 어떻게보면 왜 만들어졌는지?, 왜 필요하지?에 대한 답변이라고 생각한다
예를 들어 velog, medium 등의 웹 서비스를 보자
해당 웹은 글을 작성하여 남에게 알리기 위한 포스팅 서비스를 제공하므로, 도메인은 포스팅이라고 할 수 있다
스타벅스는 사용자에게 커피를 판매하므로, 커피 판매가 도메인이라고 할 수 있다
이런 식으로 내가 고객에게 뭘 제공할 수 있는가?를 고민하는 것이 중요하다
2. 도메인 분리
가장 넓은 의미의 도메인들을 정의했다면, 해당 도메인을 구성하기 위해서 어떤게 필요한지 세부적으로 분리를 한다
이를 서브 도메인(Sub Domain)이라고 하는데, 종류는 다음과 같다
- 핵심 도메인(Core)
- 일반 도메인(Generic)
- 지원 도메인(Support)
🌟 핵심 도메인
상위 도메인을 가장 잘 나타내는 핵심 개념이라고 할 수 있으며, 가장 중점적으로 생각해야 하는 부분이다
단순하게 품목을 사고파는 서비스를 생각하자면 도메인은 주문이 될 수 있다
그리고 주문의 핵심 도메인은 주문이 된다
그러나 만약 여러 업체에게 주문 서비스를 제공한다 라는 개념이 추가된다면,
주문의 핵심 도메인에는 주문과 업체 관리가 추가되게 된다
🌟 지원 도메인
핵심 도메인을 만드는데 있어서 필요한 개념들을 말한다
핵심 도메인을 좀 더 돋보이게 한다던가, 부가 기능의 느낌으로 생각하면 된다
주로 간단하게 구현하거나, 솔루션을 쓰는 등의 처리를 한다
그렇지만 가지고 있는 의미가 커져서 핵심 도메인으로 변할 수도 있다
오늘의 집 같은 서비스를 생각해보자
단순히 배치도를 2D 이미지로 제공한다면 설계 도메인의 지원(Support)이 될 수 있으나,
만약 3D로 둘러볼 수 있게끔 제공한다라고 하면 이는 또다른 핵심 도메인이 된다
🌟 일반 도메인
회사가 차별점을 두고 생각해 볼 것이 아닌, 누구나가 공통적으로 가지고 있는 도메인을 말한다
굳이 이걸 신경 쓸 필요가 있나?라는 것들이 바로 이것이다
하지만 이또한 비즈니스로 어떻게 생각하는지에 따라 핵심 도메인으로 변할 수도 있다
예를 들면 인증/인가, 메일 전송, 결제 등은 어디에나 있는 기능들이다
이미 다들 사용하고 있는 기능이기에 차별점을 둘 필요가 없다
하지만 보안 솔루션을 개발하는 입장이라면 이는 핵심 도메인이 된다
이렇게 나누는게 간단해보이지만, 이후의 구현에서 초석이 되는 작업이다
따라서 도메인들이 나중에 보니 서로 겹친다거나 하는 일이 없게 잘 분리하여야 한다
특히 핵심 도메인과 지원 도메인을 잘 나누지 않으면, 엉뚱한 부분에 집중 개발하는 사태가 벌어지니 매우 유의하여야 한다!
3. 도메인 이벤트 떠올리기
앞 단계에서 잘 분리했다면 이제 각 서브 도메인에 대해 본격적으로 생각해볼 때이다
도메인 이벤트란 무엇인가?
각 도메인 내에서 사용자가 S/W 대상으로 할 수 있는 이벤트(행동)를 말한다
예시를 들자면 다음과 같다
- 장바구니에 담겼다
- 주문 가능한 목록을 보여준다
. . .
이 부분은 보통 포스트 잇을 보드나 벽에 붙여서 의견을 제시한다고 한다
필자는 텍스트로 작성하는 방식으로 진행했는데, 포스트 잇이 훨씬 다같이 의견을 낸다는 느낌이 강하고 간결한 방식인 것 같다
4. Event 프로세스 완성하기
Domain Event를 누가 발생시켰고, 무엇때문에 발생했는지를 생각하며 하나의 프로세스를 완성시킨다
예를 들면 다음과 같다
- 사용자 -> 장바구니 추가 -> 장바구니에 담겼다
- 사용자 -> 주문 목록 조회 -> 주문 가능한 상품 목록을 보여준다
생각하는 도중 외부 서비스가 필요하다면 추가해준다
가령 상품 목록이 자사가 아닌 다른 회사의 정보라면 이는 외부 서비스가 된다
- 사용자 -> 주문 목록 조회 -> 품목 조회 시스템 -> 주문 가능한 상품 목록을 보여준다
생각을 하다보면 Event가 추가로 생각나거나, 의미가 겹치는 Event가 생각날 수도 있다
이때는 다시 전단계로 돌아가면 된다
느낀점?
사실 실제 프로젝트를 진행 시 이렇게까지 확실히 나눠서 진행하진 않았다
그러니까 도메인을 생각해보자!라던가 도메인을 분리해볼까? 하진 않았다는 것이다
그냥 중점적으로 생각하는 도메인이 이런 것이고, 이것 위주로 개발하자
로그인은 공통 기능이니 우선순위는 뒤로 빼두고 A 기능 먼저 진행해요
이런 식으로 말이다
그러니보니 체계적으로 진행한다는 느낌은 받았으나, 내가 진행하는 각 단계에 어떤 의미가 있는지 크게 와닿지 않았다
그러나 이렇게 단계를 나누어보니 왜 그렇게 진행을 한 것인지, 어떤 의미가 있는 것이지 깨닿게 되었다
이를 바탕으로 좀 더 나은 개발을 진행할 수 있을 것 같다
