교내에서 다른 동아리와 같이 협업하여 프로젝트를 진행하기 전에,
같이 스터디를 통해 실력을 향상시키자는 이야기가 나왔고, 그래서
스터디의 주제인 도메인 주도 개발 공부를 시작하게 되었다.
이 글은 '도메인 주도 개발 시작하기'라는 책을 읽으며
공부하고 정리한 내용이다.
도메인이란?
도메인 주도 개발을 시작하기에 앞서, 도메인이 뭘까?
수학적으로 도메인은 정의역을 뜻하기도 한다.
이게 구체적으로는 어떤 의미일까?
간단하게 예시로, 온라인 쇼핑몰 시스템을 만들 때 개발자는 어떤 기능을
사용자에게 제공해야할까?
여러가지가 있을텐데, 상품 조회, 검색, 찜하기, 구매, 배송 조회 등
여러가지의 기능을 제공해야할 것이다.
이 때 이 온라인 쇼핑몰은 SW로 해결하고자 하는 문제 영역, 즉 도메인이다.
하위 도메인
다음과 같이 도메인은 여러 개의 하위 도메인으로 구성할 수 있다.
회원이라는 하위 도메인은 고객에 대한 정보를 제공하고,
결제라는 하위 도메인은 고객의 물품 결제를 처리한다.
이런 여러가지의 하위 도메인들은 다른 하위 도메인들과 서로 연결되어
완전한 기능을 제공한다.
소프트웨어가 도메인의 모든 기능을 제공하진 않는다
하지만 OAuth나, 금융 API 등의 외부 시스템을 사용할 수도 있다.
소프트웨어가 도메인의 모든 기능을 제공하진 않는다는 것을 알아두자.
도메인 전문가와 개발자 간의 지식 공유
정산이나 배송, 주문 등의 영역에는 전문가가 있는데, 이를 도메인 전문가라 한다.
도메인 전문가와 개발자의 입장에서 협업할 때 어떤 주의점이 있을까?
요구사항 이해
전문가들의 경험이나 지식을 바탕으로 기능 개발을 요구할 때,
개발자들은 이 사항들을 분석 및 설계해 코드를 작성한다.
이 때, 제일 중요한 점은 요구사항을 올바르게 이해하는 것이다.
처음부터 요구사항을 이해하고 설계해야 코드를 작성할 때
이상한 기능을 개발하거나 하는 등의 결함이 생기지 않을 것이다.
그렇다면 요구사항을 올바르게 이해하려면 어떻게 해야할까?
직접 대화하기
제일 간단하고 당연한 방법이지만, 전문가와 직접 대화해야한다.
개발자와 전문가 사이에 전달자가 많으면 정보가 왜곡되고 손실이 발생한다.
또한 개발자가 전문가 만큼은 아니더라도, 도메인 지식을 갖추고 있어야한다.
도메인 전문가와 관계자, 개발자가 지식을 공유하고 소통할수록 전문가가
원하는 제품을 만들 가능성이 높아진다!
꼭 전문가와의 협업이 아니더라도, 꼭 개발할 때 다른 전문가들과 직접 많은
대화를 하며 서비스를 설계하는 습관을 들여보도록 하자.
도메인 모델
도메인 모델은 뭘까?
제일 기본적으로 도메인 모델은 특정 도메인을 개념적으로 표현한 것이다.
도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 도메인을 이해하고
지식과 요구사항을 공유하는데에 도움이 된다.
도메인 모델은 객체나 ERD, 그래프 등 다양한 방식으로 모델링할 수 있다.
그렇다면 이제 도메인 모델을 작성하는 패턴에 대해 알아보자.
도메인 모델 패턴
일반적으로 애플리케이션의 구조는 다음과 같은 네 개의 영역으로 구성된다.
다음 구조에 대해 짧게 알아보자.
아키텍처 구성
사용자 인터페이스 (표현)
사용자의 요청을 처리하고 정보를 보여준다.
응용
사용자가 요청한 기능을 실행한다.
도메인
시스템이 제공할 도메인 규칙을 구현한다.
인프라스트럭쳐
데이터베이스나 메시징 시스템 등의 외부 시스템과의 연동을 처리한다.
이와 같이 살펴본 도메인 모델은 도메인 자체를 이해하는 데에 필요한 모델이고,
도메인 모델은 아키텍처 상의 도메인 계층을 객체 지향 기법으로 구현하는 패턴을 이야기한다.
이제 이 모델들을 도출시켜보자.
도메인 모델 도출
도메인 모델은 요구사항을 전부 분석하여 구현하며 도출할 수 있다.
만들어진 모델은 도메인 전문가나 다른 개발자와 논의하는 과정에서 공유하기도 한다.
모델을 공유할 때는 화이트보드나 위키 등의 도구를 사용해 누구나 볼 수 있게 하는 것이 좋다.
이제 모델을 구성하는 구성요소들에 대해 자세하게 알아보자.
엔티티와 밸류
이런 식으로 도출한 모델은 크게 엔티티와 밸류로 구분한다.
하나씩 특징들에 대해서 알아보자.
엔티티
엔티티의 특징은 식별자를 가진다는 것이다.
엔티티 객체마다 고유한 식별자를 가지는 것이 특징이다.
식별자는 바뀌지 않으며, 속성을 생성하고 바꾸고 삭제할 때까지 유지된다.
밸류 타입
밸류 타입은 개념적으로 완전한 하나를 표현할 때 사용한다.
개념적으로 같은 의미를 가지는 밸류들을 모아 표현한다.
이는 밸류 타입을 위한 기능을 추가할 수 있고 코드를 이해할 때 도움이 된다는 장점이 있다.
그런데 보통 밸류 타입은 불변으로 구현한다. 왜 그럴까?
밸류 타입이 불변인 이유가 뭐야?
여러가지의 이유들이 있지만, 가장 중요한 이유는 안전한 코드 작성이다.
만약 객체를 전달해야 하는데, setter를 제공하여 값을 변경할 수 있다면
값이 잘못 반영되는 상황이 발생한다.
이런 문제를 방지하기 위해 새로운 객체를 생성해 생성자를 통해
값을 지정해주고 불변성을 유지하여 안전하게 값을 사용할 수 있다.
도메인 용어와 유비쿼터스 언어
코드를 작성할 때 매우 중요한 역할을 하는 용어에 대해 알아보자.
도메인 용어
도메인에서 사용하는 용어를 코드에 반영하지 않으면,
개발자에게 코드의 의미를 따로 해석해야하는 부담이 있다.
따라서 도메인에서 사용되는 도메인 용어를 사용해 코드를 작성하면,
불필요한 변환 과정을 거치지 않고 직관적으로 코드를 이해할 수 있다.
유비쿼터스 언어
에릭 에반스는 언어의 중요함을 강조하기 위해 유비쿼터스 언어라는 용어를 사용했다.
전문가와 관계자, 개발자가 도메인 관련 공통 언어를 만들고,
모든 곳에서 같은 언어를 사용해 모호함을 줄이고 해석 과정을 줄일 수 있다는 장점이 있다.
내 친구들도 프론트엔드 개발을 할 때 용어나 컴포넌트명에 대해 굉장히
고민을 많이 하는 것을 본 적이 있는데, 나도 도메인 용어에 알맞는 단어를
찾는 시간을 아까워하지 않아해야겠다.
마무리
이런 식으로 도메인 주도 개발이 무엇인지에 대해 공부해보니,
무언가 아직은 모호한 면이 있으면서도 어느정도 내 머릿속에 이 개념이
자리잡은 것 같아서 유익했다!
실제로 책을 열심히 읽은 후, 협업할 때 이런 도메인 주도 개발 원칙을
지켜가며 개발을 해보아야겠다.
