[독서]도메인 주도 개발 시작하기
요즘 부쩍 독서에 취미 붙이는 것이 삶을 살아가는데 있어 중요하다는 생각을 했습니다.
그리고 IT 또는 회사 생활 등 여러 카테고리의 책을 읽는 것을 습관화 하려 마음 먹었습니다.
어떤 책을 읽어볼까 고민하던 찰나에
언제 사놓은지 기억도 가물가물한 "도메인 주도 개발 시작하기"를 발견했고
주말에 무작정 카페에 가 읽었습니다.
여러 IT도서들과 마찬가지로 개발자로서 업무 경력이 있으면 읽기 수월한 것 같았습니다.
특히 스프링 개발 경험이 있다면 이해가 쉽고
놓치고 있었거나 실무에 도움되는 내용들을 되새김질 할 수 있었던 것 같습니다.
이번 포스팅에서는 "도메인 주도 개발 시작하기" 도서를 읽고 느낀점을 정리해봅니다.
목차
1. DDD(Domain Driven Design) 개념의 등장
DDD는 도메인 기반 디자인을 뜻합니다.
이에 대한 개념은 에릭 에반스에 의해 2006년 도메인 주도 설계에서 등장했습니다.
기회가 되면 에릭 에반스의 "도메인 주도 설계"도 한번 읽어봐야겠네요.
2. 책의 내용
2-1. 도메인 모델
이 책은 도메인 모델에 대해서 예시를 들어 설명합니다.
예시는 커머스 회사나 시스템에서 자주 쓰일 만한 주문, 회원, 결제 등입니다.
가령 서점이라는 도메인은
주문, 회원, 결제와 같은 하위 도메인으로 구성 할 수 있다고 말합니다.
그리고 개발자와 이해관계자(기획자 등)이 모두 도메인에 대한 기본지식이 있어야
제품을 개발할 수 있다고 말합니다.
Garbage in, Garbage out위 문구가 특히 기억에 남네요.
잘못 된 입력이 들어가면, 잘못된 결과가 나온다는 뜻입니다.
개발자로 일하면서 공감되는 문구인 것 같네요...😧
그외에도 아래와 같은 내용은 기억할만 합니다.
- 도메인 모델에서 불변객체를 사용하는 이유는 쓰레드와 참조투명성 측면에서 안전하기 때문이다.
- 도메인 Class에서 set 메서드를 무조건적으로 추가하지 않아야한다. 도메인 지식이 코드에서 사라지기 때문이다.
2-2. 애그리거트
이 책에서는 애그리거트라는 단어가 자주 등장합니다.
애그리거트는 하위 도메인의 묶음을 뜻합니다.
하나의 애그리거트는 하나의 도메인 또는 2-3개의 도메인으로 구성됩니다.
애그리거트가 하나의 트랜잭션 단위가 되기도합니다.
그러나 한 트랜잭션에서 2개의 애그리거트가 변경되기도 합니다.
또한 이 책에서는 JPA를 기준으로 애그리거트를 구현하는 방법을 소개합니다.
@OneToMany 등과 같은 어노테이션으로 이를 쉽게 구현 할 수 있습니다.
동시에 N+1, 성능 문제 등의 오용 위험도 있다고 말합니다.
저는 경험상 애그리거트를 @OneToMany등으로 구현했을때
장점보다는 단점이 더 와닿았던 것 같네요.
책이 말하는 문제(잘못된 이해와 오용으로 인한 성능 이슈, 복잡한 코드 등)가 너무 공감되었습니다.😥
2-3. spring-data-jpa 예제 코드들
이 책에 포함된 예제코드들은 과거에 한번쯤 사용해봤을 법한 코드들입니다.
다만, 과거 버전이거나 개인적으로 사용이 꺼려지는 API들을 소개하고 있어 훓고 넘어 갔습니다.
2-4. 응용 서비스와 표현 영역
응용 서비스 영역에서의 자주 사용되는 함수는
도메인 계층에 개발한다면 중복을 줄일 수 있다고 합니다.
checkPassword와 같은 유효성 체크 함수를 응용서비스 영역(ex. ModifyMemberService)에 배치하기 보다는
도메인 영역(ex. Member class)에 두는 것이 효율적이라 말합니다. 이렇게 되면 새로운 요구에 의한 응용서비스 영역(ex. DeactivatePasswordService)에도 재사용 가능 하기 때문입니다.
또한 스프링 개발자 사이에서 논쟁이 있던 아래 물음에 대한 답변도 다루고 있습니다.
서비스(Service)를 만들때 인터페이스(Interface)를 작성해서 구현하도록 해야하는가?
이 책에서는 여러 구현체가 존재하지 않는 이상은 안쓰는게 좋다고 말하네요.
또 테스트 코드 작성을 위해서 interface를 쓰곤 했는데
요즘은 Mockito같은 라이브러리가 있어 하나의 응용 서비스 구현체만 있다면 굳이 interface를 사용하지 않아도 된다고 합니다.
그리고 응용 서비스 계층과 표현 영역 간 서로 침범하지 말기를 강력히 말합니다.
스프링에서 Service에서 HttpServletRequest나 HttpSession같은 것을 참조해서 사용하지 말라는 것입니다.
아마도 현업에서 기능 개발하다 보면 영역간 서로 침범하여 작성된 코드를 직면할 수 있는데...
유지보수 측면에서 굉장히 비효율적이었던 경험이 있네요.
코드가 복잡해지고, 이는 디버깅을 어렵게 하고 테스트 작성을 까다롭게 합니다.
2-5. 헬퍼 클래스
여러 응용 영역에서 공통으로 사용되는 기능을
헬퍼 클래스(Helper Class)로 구현하는 것도 인상적인 내용이었네요.
메모메모...😃
3. 마치며...
위 소개한 내용들 이외에도 현업에서 충분히 다룰 만한 내용들이 포함되어 있습니다.
- 트랜잭션 범위
- 마이크로서비스 아키텍쳐(MSA)
- 이벤트 기반 시스템 디자인
- CQRS
- 등등...
백엔드 개발자. 특히 스프링을 주로 사용한다면 한번쯤 읽어 볼만한 책이었던 것 같습니다.
본인이 그간 관습적으로 작성해오던 자바 코드와 패키지 구조 등을 다시한번 되돌아 볼 수 있도록 합니다.
저는 무조건적인 디자인 패턴 적용은 꺼려합니다.
가령 무지성 DDD를 강요한다면 오히려 반감이 생기더군요.
이 책은 현업에서 발생한만한 이슈들을 예로 들며 은탄환(Sillver Bullet)은 없음을 간접적으로 이야기 하는듯 했습니다.
적용했을 때 이점과 불리한 점들을 근거와 함께 소개하는 방식이 인상적이었습니다.