마치 퍼즐이 완성되어가는 기분이 든다 (도메인 주도 개발 시작하기)

 

 

 

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다...만
진심이 담겨있습니다. 허위 사실 유포는 😎일절 없음.

 

 

이거 찍으러 나간거 아님. 진짜 아님. 아무튼 아님.

 

개발자들은 정말 많은 DD들을 봐왔을 것이다. TDD (Test-Driven-Development), BDD (Behavior-Driven-Development), DDD (Domain-Driven-Development) 등등. 그 중 이번에 다룰 책은 DDD을 소개하는 서적이다. 그리고 왜 이런 책이 이제 나왔나 싶다. 리뷰어 활동으로 적고 있는 글이지만 많은 분들에게 "도메인 주도 개발 시작하기"를 추천하고 싶다. 이유는 뒤에 소개하기로 하고 어떤 분에게 추천하는지 아래에 서술해보자면...

 

• 어줍잔게 백엔드 개발을 시작했는데 아직도 주먹구구식으로 업무를 하는 개발자
• 경험이 적어서 기존 기능을 복붙하는 주니어 개발자
• JPA와 스프링을 1번 정도 경험은 했지만 이게 왜 이렇게 돌아가는지 모르는 개발자
• 다른 개발 분야는 경험했지만 백엔드는 이제 처음인 개발자
• JPA와 스프링을 1회 이상 공부한 개발자 등에게 추천!!!

 

단연코 얘기할 수 있다. 마치 퍼즐이 완성되어가는 기분을 느낄 수 있다. "아. 이게 그래서 이렇게 사용했던 거구나." "이런 이유로 이런 이름을 사용했구나." "이래서 불필요해 보이는 코드를 추가했어야 했구나" 깨달음을 얻듯이 소름끼치는 순간이 여러번 다가온다.

 

이런 깨달음을 이제야 얻는 이유는 하나다. 지금까지 주먹구구식으로 배운걸 바탕으로 어거지로 개발을 했기 때문이다. 그러면 "이렇게 하면 되는건 알겠는데 왜 되는지는 모르겠다"의 상태가 된다. 일단은 기능 구현이 되니깐. 그래서 개발을 하는데 면접 등에서 왜 이렇게 했는지 물어보면 대답을 못한다. 누구 얘기냐고? 저요 저요

 

 

 

적절한 그림과 직관적인 코드로 인해 하나씩 실습하지 않고 책만 보아도 이해가 잘 된다.

 

"도메인 주도 개발 시작하기"의 장점은 굳이 책 속의 샘플 코드를 하나씩 구현하지 않아도 충분히 직관적인 예시를 제공하고 있다는 것이다. <주문>이라는 도메인을 중심으로 어떻게 사고하는지, 어떻게 코드를 작성하는지 직관적으로 보여준다. 스프링과 JPA를 1년 정도 다뤄본 분이라면 코드를 읽기만 해도 예시의 의도를 충분히 파악할 수 있다. 

 

구성도 좋다. [챕터1]에서 DDD를 찍먹해본다. 이미 이때부터 "아니 이런거였어?"라고 무릎을 탁 친다. [1.6 엔티티와 밸류]에서 왜 모든 프로퍼티를 하나의 엔티티에 쑤셔넣지 않고 이렇게 밸류를 가지고 가는지 알게 된다. 하지만 이건 [챕터1]. 아직 찍먹이다. 찍먹에서조차 나같은 미숙한 개발자는 무릎을 치게 만드는 순간이 있었다.

 

메타몽도 무릎을 치고가는 "도메인 주도 개발 시작하기"

 

 

 

 

[챕터2]에서는 앞으로 다룰 내용들의 개요를 설명하고 [챕터3]부터 본격적인 DDD적인 학습이 시작된다. 개인적으로는 [챕터7]까지가 DDD의 기본이 아닐까 싶다. 아키텍처의 각 영역 설명이 [챕터7]까지 이어지기 때문. 그리고 [챕터8]부터 마지막 챕터인 [챕터11]까지는 DDD의 응용편으로 생각하면 된다. 만약 [챕터7]까지 학습을 하고도 DDD적인 사고와 개발이 안된다면 [챕터8]로 넘어가지 말고 다시 [챕터3]부터 학습하는걸 권장한다.

 

나는 안드로이드 개발자 출신이다. MVC, MVP, MVVM 등등의 디자인 패턴을 실무에서 쓰니깐 당연하듯 사용은 했지만 항상 의문이 있었다. "Repository라는건 반드시 있을 필요가 없는데 왜 많은 시스템에서 사용하고 있지?" 모바일보다 역사가 오래된 백엔드쪽에서는 이미 Repository 개념을 사용하고 있었다. 유저에게 UI를 보여주는게 목적인 안드로이드 개발과는 다르게 백엔드는 데이터를 전달하고 저장하는게 중요하기에 영속성 처리를 위한 수단이 필수적이다. 이런 이유로 백엔드에서는 Repository를 사용했고 모바일 개발에서도 그 영향을 받아 데이터를 다룰 때 Repository가 등장하는 경우가 있었던 것이다. 모바일에서는 데이터를 백엔드로부터 전달을 받아서 가공하고 보여주는게 목적이니 영속성 처리에 민감할 일이 없다. 게다가 안드로이드는 라이프사이클이 프레임워크 자체에 견고하게 반영되어 있어서 더욱 그렇다. 이 깨달음 과정을 "도메인 주도 개발 시작하기" 덕분에 알게 되었다.

 

위 사례 외에도 많은 깨달음이 있었다. JPA의 엔티티와 도메인 엔티티의 차이, 도메인을 자세하게 분리하는 이유, 패키지 설계 방법 등. 이런 깨달음 때문에 이 책은 단순한 기술서라기 보다는 사고하는 방식을 바꾸는 책이라고 설명하고 싶다. 혹시나 나와 비슷한 처지였고 이 깨달음이 궁금한 분들은 "도메인 주도 개발 시작하기"를 펼쳐보자.

 

 

 

도메인 주도 개발 시작하기 - YES24

 

📚