이번 기회에 도메인 주도 개발 시작하기 책을 읽게 되었다. 책을 읽어보면서 한편으로는 ddd 개념을 제대로 이해하지 못한채 개발을 하긴 했지만 얼추 태는 비슷하다고 느꼈다. 책을 읽으면서 에그리거트라는 큰 개념을 보게 되었다. 혼자 스타트업에서 백엔드 개발을 하다보니 기존 코드에 추가 요구사항을 더 하면서 도메인이 많아지게 되었다. 해당 문제를 어떻게 해결해야할지 고민 이였는데 에그리거트가 해당 문제를 해결 해줄 것 같았다.
여러분은 도메인이라는 단어에 대해서 어떻게 이해하고 있는가? 도메인이라고 하면 http 주소가 생각 나기도 하고 데이터베이스의 모델을 말하는 것 같기도 하고 큰 맥락에서 어떤 영역의 소프트웨어인가를 나타내는 말로도 쓰이는 것 같다.
DDD에서 도메인은 소프트웨어가 해결하고자 하는 문제의 영역을 의미합니다. DDD에서 도메인은 비즈니스 도메인을 의미하며, 비즈니스 도메인은 유사한 업무의 집합이다.
도메인 모델은 도메인의 개념과 규칙을 표현한 모델이다. 도메인 모델을 통해 도메인의 구조와 동작을 이해할 수 있다
다음의 도메인 모델 패턴은 엔터프라이즈 애플리케이션 아키텍처 패턴 책의 도메인 모델 패턴을 의미한다.
위 도메인 모델 패턴은 계층 구조인데 표현이 가장 위이고 인프라스트럭처가 가장 아래이다. 위와같이 계층을 나누어 코딩하게 되면 추상화 수준에 맞는 코드를 모아두게 되어 이해가 잘 될 것이다. 따라서 유지보수도 하기 쉬워진다. 그리고 DIP 개념을 통해 하위 계층이 상위 계층을 의존하도록 하여 코드도 클린하게 만들 수 있다.
도메인 용어란 도메인이 가지는 상태 값의 경우 코드만 보더라도 도메인이 어떤 상태인지 알게 개발 할 수 있도록 하는 것이다.
도메인 용어가 필요한 이유는 코드를 보고 바로 이해할 수 있도록 하기 위함이다.
예를 들어 인터넷에서 물건을 주문한다고 생각해보자. 이 때 주문 도메인을 통해 고객의 주문을 관리하고 고객이 주문 내용을 작성 중일 땐 주문 대기, 그리고 작성 완료 및 결제가 되었을 때 주문 요청 완료 상태로 변경 될 것이다. 여기서 주문 대기, 주문 요청 완료가 도메인 용어가 된다. 만약 도메인 용어를 사용하지 않고 step1, step2 이런 식으로 상태 값을 다룰 경우 나중에 다른 개발자가 해당 코드를 인수인계 받았을 때 코드를 재 해석해야하는 어려움이 있을 수 있고 나중에 본인이 봐도 무슨 코드인지 알기 힘들 것이다.
따라서 유지보수성을 위해서 도메인 용어는 필요하다.
유비 쿼터스 언어는 개발자와 도메인 전문가가 도메인과 관련된 공통의 언어를 만들고 이를 대화, 문서, 도메인 모델, 코드, 테스트 등 모든 곳에서 같은 용어를 사용하는 것이다. 이를 통해서 개발자와 비개발자간에 협업이 원할하게 진행된다.