DDD 아주 살짝 맛보고 후기 남기기

목차

1. DDD를 접하게 된 이유와 매력

• 유비쿼터스 언어
• 간접 참조와 수직적인 의존 관계의 늪

---

DDD를 접하게 된 이유와 매력

 

 

 

도메인 주도 설계를 처음 접하게 된 건 위 책의 구판인 DDD START!다. 프로젝트에서 알림 기능을 구현해야 했다. 실시간 알림이었는데 SSE로 구현하기로 결정했었다. 관련 소스를 찾아보았는데 어떤 사이트에서 EventListenter를 사용하는걸 보았다. 도대체 저건 무엇일까? 여기 저기 찾아보다가 공식문서를 보게 되었는데 도통 무슨 말인지 알 수 없었다.

 

그러다가 위 책에서 이벤트리스너에서 대해 다루는 것까지 알게되어 바로 구매하게 되었다. 그렇게 후반부에 있었던 이벤트 리스너를 공부하고 책을 덮게 되었다. 

 

그렇게 프로젝트를 마무리하고 취업 공고를 보는데 종종 도메인 주도 설계에 대한 이해가 우대사항에 적혀있는걸 볼 수 있었다. 도대체 DDD가 뭐길래 우대까지 하는걸까? 하는 생각에 책을 읽었다.

 

 

내가 이해한 DDD의 한 부분은 위와 같이 수평적으로 연결되어 있는 프로젝트를 구조를 수직적으로 변경하는 것이다. 많은 이유가 존재할 것이다. 그럼에도 수평적으로 얽히도록 만드는 이유가 무엇일까?

 

1. 무엇보다도 개발하기 쉽다.

2. 보통 한 프로젝트에는 한 개의 DB를 연동한다.

 

그럼 왜 DDD에서는 이를 도메인 별로 수직적으로 분리하려고 할까? 다양한 이유가 있겠지만

 

1. 확장에 유리하다. 의존이 수직적이라면 프로젝트를 분리하기 편하다. 예를 들면 상품, 주문, 리뷰 도메인이 있을 때 각 도메인을 분리해서 서버를 배포할 수 있다는 것을 의미하기도 한다.

---

유비쿼터스 언어

도메인 주도 개발 시작하기 책을 금방 덮지 않을 수 있었던 이유는 유비쿼터스 언어 때문인 것 같다. 과거에는 개발을 할 때 변수 명, 메서드 명은 적어도 다른 동료가 이해할 수 있게 짜려고 노력했다. 하지만 타입은 타입은 자바의 기본, 래퍼 타입을 쓰는 경우가 압도적으로 많았던 것 같다.  물론 모든게 트레이드 오프겠지만 타입을 객체로 두면 모두가 이해할 수 있는 보편적인 언어가 될 가능성이 높아진다.

 

 

놀랍게도 최대한 유비쿼터스하게 짜려고 노력한 코드이다. 스터디 그룹은 그룹 상태, 기간, 시간, 인원, 방장, 멤버, 체크리스트를 가진다. 이렇게 말하고보니까 장황한데 값 타입을 사용하지 않으면 최소 2배 이상 복잡하게 설명해야 한다.

---

간접 참조와 수직적인 의존 관계의 늪

유비쿼터스 언어에서 다시 돌아와서 DDD의 목표 중 하나는 프로젝트 의존 구조를 도메인 별로 수직적으로 가져가는 것이다. 말은 쉬워보였지만 @ManyToOne, @OneToOne 을 사용해서 직접 참조를 맺던것에 익숙했던 나에게 간접 참조는 조금 다소 충격적이었다.

 

 

groupMemberId를 통해 Group과 Member 연관 관계를 맺는다.

 

 

DDD에서 말하는 간접 참조를 지킨다고 해서 프로젝트 내 도메인 별 의존 관계가 수직적이게 되는 것은 아니다. 아래와 같이 Application 레이어에서 다른 도메인의 infra 계층이 필요해? 보일수도 있다.

 

 

그래서 제가 짠 코드처럼 Group 도메인에서 StudyProduct라는 도메인 내 객체를 의존받게 될 수도 있다. (물론 이문제를 해결할 수 있다.) 책을 자세히 살펴보면 해결책이 나오긴 하겠지만 나는 DDD START! 수다 #1 영상에서 많은 힌트를 얻게 되었다. 다음 포스팅은 위처럼 A도메인에서 B도메인을 의존하는 문제를 해결하는 방법을 다뤄보려고 합니다.