[DDDStart] 1장. 도메인 모델 시작

17 Jun 2021

1장. 도메인 모델 시작

도메인 모델이 무엇인지 알아보고 엔티티와 밸류에 대해 언급한다

소프트웨어로 해결하고자 하는 문제영역

도메인 자체를 이해하기 위한 개념 모델

도메인 모델을 객체로만 모델링할 수 있는 것은 아니다.

도메인을 이해하는데 도움이 된다면 다 오케이임. 표현 방식(상태 다이어그램, 그래프, 클래스 다이어그램)은 중요하지 않음

관계가 중요한 도메인일 경우 그래프를 이용해도 됨

어쨌든 여러 관계자들이 도메인을 동일한 모습으로 이해하고, 도메인 지식을 공유하는데 도움이 된다면 도메인 모델이라고 할 수 있음

(레이어드 아키텍쳐의 네 개의 계층 중 도메인 계층을 구현할 때 사용하는 객체 모델을 언급할 때에도 도메인 모델 이란 용어를 사용함)

TODO:: (int -> Money, String->Email)

도메인을 이해하려면 도메인이 제공하는 주요 기능과 데이터를 파악해야 함.

기능과 데이터를 할께 보여주는 객체 모델은 도메인을 모델링하기 적합하다.

Layer	설명
UI/Presentation	사용자의 요청을 처리
Application	사용자가 요청한 기능을 실행 (도메인 계층을 조합해서 기능을 실행함)
Domain	도메인 규칙 구현
Infra	DB / Messaging 등의 외부 시스템과의 연동

요구사항이 9개 있음. 요구사항을 보고 설계를 해봤을 때 책이랑 똑같이 나오는지 나중에 해보기로 함.

VO는 코드의 의미를 더 잘 이해할 수 있도록 한다.

도메인을 더 깰꼼하게 표현함.

Money.class, 일급 컬렉션, OrderId.class 등이 해당함.

VO를 이동시키면서 변경될 여지가 있기 때문에 불변 객체로 만듬.

지금껏 개인 프로젝트할 때 VO는 따로 만들지 않았었음.

굳이 만들 이유가 있나? 왜 만들어야 하는지에 대한 의문이 들었었는데,

단순히 코드를 보기 좋게 작성하는 것 뿐만 아니라, 도메인 관점에서 코드가 도메인을 잘 표현해야 비로소 코드의 가독성이 높아진다.

라는 문장을 보고 VO를 만드는 것이 가독성을 돕는다고 생각하니 납득이 갔음.

Q1. 우리가 만드는 프로젝트는 도메인 모델인가?

도메인 레이어를 도메인 모델이라고 말한다고 위에 있었음.

실제로 프로젝트를 한다면 별도의 UML로 표현하는 것이 코드보다 도메인을 더 이애할 수 있을 것임.

코드만을 본다면 처음에는 Application Layer 부터 보면 좋을 것 같음. 도메인들이 어떻게가 아닌 무엇을 하는지 알 수 있음.

Q2. verifyNotYetShipped()의 state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING 은 enum에서 처리해야 하는거 아닌가? (p16)

그런 거 같은데..

Q3. 개발할 때 요구사항에 따라 도메인 로직들을 먼저 만들던데.. 그럼 4 계층 중에 도메인 영역을 먼저 개발한다고 보면 되려나? (p11)

Q4. 식별자도 (OrderNo) 도 도메인을 표현하는 걸로 봐야하나?

당근. 이것도 도메인의 이해를 돕기 위해 나온 거임.

Q5. Money.class 의 private int value에 final을 왜 안붙인거지??? (p27)

final 붙이면 더 직관적으로 표현할 수 있긴 하지만 어쨌든 여기서 수정하는 로직이 없긴 함. 문제되진 않음. (DDD 공부 안하고 이상한거 계속 지적함)

Q6. 안불변객체는 스레드에 왜 안안전해? (p28)

A쓰레드가 참조하고 있는 객체를 B쓰레드가 바꿔버릴 수 있잖아.. 힙영역 생각하자.

Q7. setter 를 private로 두고 , 관련된 로직을 저렇게 넣을 수도 있구나… (p33)

공통적으로 처리해야할 로직이 있다면 저렇게 쓰면 좋을 것 같음. 자바 처음 배울 때 저거 배웠던거같은데ㅋㅋㅋ 한번도 저렇게 안써봤네.