도메인 주도 개발 시작하기를 읽게 된 계기

이전에 객체지향의 사실과 오해(조영호 지음) 을 읽고 나니 조금 더 객체지향을 공부해 보고 싶은 욕구가 생겼고 방법은 여러가지가 있었다.

  • 객체지향 언어에 대한 공부
  • 객체 설계에 대한 공부

이런 고민을 하던 중 우테캠 교육과정을 같이 수강했던 인원들과 ‘도메인 주도 개발 시작하기’
라는 책으로 스터디를 모집한다는 소식을 접하게 되었고, 객체지향에 대한 심도있는 학습의 수단으로서
이 책을 읽게 되었다.

데이터 중심에서 도메인 중심으로

개발이란 일을 업으로 삼다보면, 개발 기술에만 초점이 맞춰지고 그것만이 진리라고 느껴지는 때가 가끔 들긴한다.
물론 개발을 잘하는 것은 정말 매우 중요하다. 하지만, 개발 실력만큼 중요한 것은 바로 협업하는 능력이라고 생각한다.

이 책의 1장인 ‘도메인 모델 시작하기’ 에선 위에서 말한 협업 능력과 개발 능력을 어떻게 조화롭게 소화하는 지에 대한 방법이 설명되어 있다.
각 도메인 모델엔 전문가가 따로 있다. 개발자는 도메인 모델 전문가와 적극적으로 소통하며, 모델을 시스템에 어떻게 녹여낼 지
도메인 전문가와 협업 해야 한다. 그리고 충분한 협업으로 도메인에 대한 이해를 바탕으로 그 도메인 모델을 구현 해내는 데에는 개발 능력이 필요하다.

도메인 전문가와의 협업이 없으면 개발자는 당연하게도 데이터로부터 모든 비즈니스 로직을 도출할 수 밖에 없다.

도메인 모델 vs 애그리거트 vs 바운디드 컨텍스트

책을 읽다보면 도메인, 애그리거트, 바운디드 컨텍스트 같은 단어들이 휘몰아쳐서 길을 잃기 쉽상이다.
따라서 아래와 같은 단어는 반드시 개인적으로 개념을 숙지해야한다.

  • 도메인 모델 : 소프트웨어로 해결해야하는 가장 큰 개념 혹은 논리
  • 애그리거트 : 일관성을 위해 관련 도메인 개체를 그룹화
  • 바운디드 컨텍스트 : 관리 용이성을 위해 큰 도메인 모델을 더 작은 부분으로 나누는 방법
    • 같은 용어에 대해 다른 의미로 사용하고 있다면 바운디드 컨텍스트를 나눠야 하는 지 의심해야함

어떻게 도메인 중심으로 개발하나요?

크게 보면 아래와 같이 2가지 방식이 도메인 주도 설계의 핵심 방법이다.
방법에 따라 특징이 아래와 같고, 각 방법에 따라 장/단점이 나뉜다.

  • Layered Architecture : 표현, 응용, 도메인, 인프라스트럭처 로 계층을 나누고 상위에선 하위 계층으로만 의존한다.
  • Hexagonal Architecture(포트 및 어댑터라고도 함) : 외부 시스템과의 통신을 처리하는 어댑터와 포트가 도메인 모델을 둘러싸고 있는 형상

가만 읽다보면 architecture 에 집중하도록 할 것 같은데,
개인적으로 가장 중요한 것은 도메인 간 의존성 혹은 계층 간 의존성이라고 느껴졌다.

객체지향 밸런스

도메인 모델로 시작해서 핵심 비즈니스 로직을 도메인에 집중시키는 방법은 객체지향과 그 결이 같다고 느껴졌다.
하지만, 책을 읽으면 읽을수록 도메인 서비스나 CQRS 등 도메인 모델과 애그리거트가 조금 더 독립성(?)을 갖도록 해주는 여러 도구들에 대해 설명해준다.

맨처음 이 부분을 읽을때는 정 반대의 개념을 설명하면서 ‘도메인 모델에 대한 모순이 아닌가?’ 싶었지만,
곰곰히 다시 생각해보니 결국 애그리거트의 응집도를 높이기 위해 결합도를 낮추는 방법에 대한 이야기였다.

생각해보자

백엔드 개발자로 일을 하다보면 ‘도메인’, ‘엔티티’, ‘스키마’ 등의 단어를 무분별하게 사용하곤 한다.
단어 하나 하나 의미를 곱씹어보면 얼마나 무분별하게 사용했는 지 이 책을 읽으며 알게되었다.
앞으론 도메인, 애그리거트, 엔티티 등등 각 의미를 알고 소통해야겠다는 생각이 들었다.

또한 다시금 이분법에 빠져선 안된다는 생각이 들었다.
이 책을 읽고나서 도메인 모델이 마치 데이터 중심의 설계보다 더 뛰어나다는 생각을 갖기 쉽상이다.
하지만, 왜 도메인 모델로 설계해야하는 지 그 이유를 먼저 생각봐야 한다.
이 책을 통해 도메인 모델 설계라는 좋은 무기를 손에 넣었을 뿐이다.

다만, 객체지향적인 관점에서 보면 도메인 주도 설계라는 방법은 꽤나 이상적이다.
도메인 전문가와 협업하면서 비교적 큰 시스템을 도메인 모델로 설계한다면 그것이 진짜 객체지향이라고 부를 수도 있을 것 같다.