[도메인 주도 개발 시작하기]1. 도메인 모델 시작하기

https://product.kyobobook.co.kr/detail/S000001810495

도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지 | 최범균 - 교보문고

Chapter 1_도메인 모델 시작하기: https://inhyeok-blog.tistory.com/55
Chapter 2_아키텍처 개요 :
Chapter 3_애그리거트 : 
Chapter 4_리포지터리와 모델 구현 : 
Chapter 5_스프링 데이터 JPA를 이용한 조회 기능 : 
Chapter 6_응용 서비스와 표현 영역 : 
Chapter 7_도메인 서비스 : 
Chapter 8_애그리거트 트랜잭션 관리 :
Chapter 9_도메인 모델과 바운디드 컨텍스트 : 
Chapter 10_이벤트 : 
Chapter 11_CQRS : 

---

 

 앞서 「가상면접 사례로 배우는 대규모 시스템 설계 기초」 리뷰를 작성하면서 했던 생각이 '다시는 챕터 별로 리뷰를 포스팅하지 않아야지'라는 것이었다. 그 당시에는 포스터 작성하는 데 걸린 시간이 독서하는 시간만큼(어쩌면 그보다 더) 길었고, 중간에는 목적을 잃어버려서 단지 시작한 일을 끝마야 한다는 의무감으로 키보드를 두들기기도 했다. 하지만 이 책을 처음 펼쳐보고 완전히 생각이 바뀌었다.

 분명 난 이 책을 읽은 기억이 없는데 책의 초반부에 밑줄과 필기가 적혀 있는 것이다! 심지어는 친구에게 내가 술을 먹고 책을 읽었던 것 같다는 농을 던지기도 했다. 반면에 「가상면접 사례로 배우는 대규모 시스템 설계 기초」 책에서 배운 지식과 얻은 인사이트는 지금도 머속에 남아서 많은 도움을 주고 있다. 그 이유는 책을 읽은 이후에도 여러 가지 이유로 해당 책에서 읽은 내용을 복기할 일이 많아서도 있지만, 분명히 그때 글을 작성하기 위해서 꼼꼼히 다시 읽어보던 시간이 의미가 있었던 것 같다. 그래서 책을 읽는 현재의 기억을 조금이라도 유지하기 위해서 리뷰를 다시 시작하려고 한다.

 그리고 리뷰를 시작하는 한 가지의 이유가 더 있는데, 생각보다 내 글을 읽는 것이 효과적으로 기억을 떠올리게 하고 재밌다는 것이다.

 

 이 두 가지의 목표 달성하기 위해 도서 리뷰를 작성하는 것이기 때문에, 앞으로 진행할 도서 리뷰에서는 조금은 많은 내용을 생략하고 필자의 입맛에 맞게 글을 작성할 계획이다. 이렇게 편한 마음으로 글을 써야 시간을 절약하고 글쓰기를 즐길 수 있게 될 것이다.

---

우선 작가는 도메인을 소프트웨어로 해결하고자 하는 문제 영역이라고 소개한다. 그리고 이 도메인은 다시 수많은 하위 도메인으로 나뉘어 질 수 있다. 예컨 온라인 서점 시스템은 그 자체로 도메인이지만 하위 도메인으로 주문, 혜택 카탈로그, 리뷰, 정산, 배송, 결제 등등을 가질 수 있다. 이 중에선 개발자가 직접 구현하는 부분도 있을 것이고 외부 시스템의 도움(배달, PG사 결제 등)을 받는 것도 있다. 그리고 도메인 주도 개발은 이 도메인이라는 개념을 가지고 큰 문제를 분할 정복한다.

 

도메인 모델은 기본적으로 특정 도메인을 개념적으로 표현한 것이다. 이때 객체 기반의 ERD일 수도 있고, State Diagram, Sequence Diagram, 어쩌면 수학적 모델 등이 될 수 있다. 어떤 형식으로 표현하는지는 중요하지 않다. 단지 도메인을 잘 표현할 수 있는 것이 중요한 것이다. 다만 도메인 모델의 종류에 따라서 구현하는 방식이 도메인 모델을 최대한 따라가게 할 수는 있을 것이다.

 

 

도메인 모델 패턴은 위에서 보이는 아키텍처 구성에서 도메인 파트에 핵심 규칙을 구현하는 것이다. 특히 비지니스 로직을 객체 지향의 특성을 적극 활용해서 구현한다. 이해를 돕기 위해서 Spring+JPA로 설명하자면, Order라는 Entity 안에 changeShippingInfo() Method를 두는 식이다. 전통적인 레이어드 MVC 모델에서는 도메인을 객체보다는 데이터의 관점으로 바라봤다. 하지만 도메인 주도 개발에서는 도메인을 객체로 바라보고 핵심 규칙을 구현해둔다.

 

소프트웨어 개발은 요구사항에서부터 시작한다. 그리고 유저 스토리와 같은 요구사항을 대화를 통해 이해하고, 도메인 초안을 만들어야 한다. 예컨데 

- 최소 하나 이상의 상품을 주문해야 한다.

- 한 상품을 한 개 이상 주문할 수 있다.

- 출고 전 배송지를 변경할 수 있다.

- 출고 후 배송지를 변경할 수 없다.

- 출고 전 주문을 취소할 수 있다.

- 고객이 결제를 완료하기 전에는 상품을 준비하지 않는다.

등의 요구사항이 있을 수 있다. 이제 이런 요구사항들로부터 도출한 상세 기능을 Order에 Method로 추가할 수 있다.

 

도메인 모델은 크게 엔티티와 벨류로 구분할 수 있다.

도메인 : 유일한 식별자를 가진다. 그리고 이 식별자는 변하지 않는다.

벨류 타입 : 개념적으로 완전한 하나를 표현할 때 사용된다. 불변성을 가진다.(객체가 변경되면 새로운 객체를 만들어야 한다.) 주소(addr1, addr2, zipCode), 사용자(name, phoneNumber), .돈(money) 등이 있다. 이때 벨류타입은 하나 또는 2개 이상의 속성을 가질 수 있다.

 

* 벨류 타입이 1개의 속성을 가지는 경우도 포함하는 이유는 Type을 통해 정체를 명확하게 표현하고, 벨류타입의 메소드로 다양한 행위를 정의할 수 있기 때문이다.

* 도메인 모델에서 set을 사용하지 말자. set은 구현을 드러내고, 도메인의 핵심 개념이나 의도를 감춘다. 따라서 의미있는 이름으로 해당 Method의 이름을 짓자.(private으로 setter를 만드는 것은 나쁘지 않은 선택이다)

 

1장을 읽으면서 도메인 주도 개발이 최대한 현실세계를 반영한 코드를 작성하려는 노력이라는 것을 느낄 수 있었다. 이를 위해서 특히 노력해야 할 점이 바로 변수 이름 정하기이다. 변수의 이름을 정하기 위해서 많은 시간을 할애하는 것을 아까워 하지 말자. 각 단어의 미묘한 차이나 뉘앙스를 파악하기 어려워도 꼭 사전을 뒤져서라도 좋은 이름을 짓자. 이는 도메인 주도개발을 통해 이루고자 하는 도메인을 더 잘 이해하는 프로그램 만들기의 최악의 적이다.