공부하는 내용을 정리하는 목적으로 작성하고 있습니다. 잘못 작성된 내용을 지적해주시면 좀더깊이 공부해서 내용을 수정하겠습니다.

Domain

• 소프트웨어로 해결하고자하는 문제영역
• 도메인은 여러개의 하위 도메인으로 구성될 수 있다.

Domain Model Pattern

• 보통 4개 계층으로 나뉘며, 상위에서 하위로 의존적이다.
  1. 표현
     • 사용자의 요청처리 및 처리결과 UI 표현 (MVC의 Controller & View)
  2. 응용
     • 사용자가 요청한 기능 수행
     • 비즈니스 로직을 직접적으로 구현하지 않고, 도메인을 적절히 순차적으로 호출하여 기능을 수행한다.
  3. 도메인
     • 시스템이 구현할 도메인 규칙 구현 (MVC의 Service)
     • 비즈니스 로직을 구현한다.
  4. 인프라스트럭처
     • DB와 같은 외부 시스템과의 연동 처리 (MVC의 DAO)

Domain Model

1. Entity
   • 고유한 식별자 존재 (ex. 주문 엔티티의 주문번호)
   • 식별자 비교를 위해서는 equals, hashcode를 알맞게 구현해야 한다.
   • 식별자 생성 방식
     1. UUID
     2. 직접 입력(ex. 회원가입의 이메일주소, ID)
     3. DB의 일련번호사용(ex. JPA GenerateValue.Idenity)
     4. 특정 규칙 사용(ex. 생성시 CURRENT DATE + TIME)
   • public set메서드를 지양하고 명확한 메서드명으로 정의한다.(ex. setState(false) -> cancel())
2. Value
   • 도메인 개념을 표현(ex. 배송의 받는사람 - 받는사람과 배송지는 동일한 대상을 가리키지만 개념적으로 구분지어 도메인을 명확하게 표현함)
   • 불변 객체 사용(builder 패턴을 이용해서 생성하는게 좋으며, 생성 외 시점에서 객체가 변경되어 무결성이 깨질 우려를 방지함)

도메인 용어

1. 반드시 의미있는 이름으로 정의한다.
   • 주문시스템의 주문상태(결제대기중 / 상품준비중 / 출고완료 / 배송중 / 배송완료 / 주문취소됨)는 반드시 누구나 알아볼 수 있는 용어 사용
   • Step1, Step2… 와 같이 한번에 알아볼 수 없는 이름을 사용하지 않는다.

이 책을 한번 완독할때는 부디 DDD에 대해 10%는 이해하기를 바라며

Domain Driven Design이라는 용어를 예전부터 많이 들어봤지만 추상적으로만 알고있었지
실제 내용이 어떤지는 그 누구에게도 설명할 수 없었다.
jojoldu님 블로그를 통해 공부하는 도중에 DDD에 혹시 조금더 봐보려든
최범균님의 DDD Start라는 책을 참고하라는 문구를 보고 구매를 했다.
쓱 훑어보고 다시 깊게 볼 예정인데

(현재 4장읽는중)

내가 업무에서 작성중인 MVC 코드들이 새삼 부끄러워진다.
물론 시스템이 과거에 개발되었고(한10년전?) 유지보수를 위해 전체적인 틀을 유지하긴했지만
정확히 도메인 개념을 모르고 작성한거랑 알고 작성한거랑은 역시 많이 다른 듯하다…..

리팩토링하고싶다.두번하고싶다.

---

DDD-START (최범균님 저) 도서 참조