일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 함수형프로그래밍
- 아키텍처
- Kotlin
- GrokkingFunctionalProgramming
- 테스트주도개발
- TDD
- Java
- 테스트
- 계층형아키텍처
- 개발서적
- 도메인 주도 개발 시작하기
- 스터디
- 조영호
- 코틀린
- template
- Boot Legacy 차이점
- DDD
- 개발방법론
- 추상화 설계
- 클린아키텍처
- web
- 객체지향의사실과오해
- Thymeleaf
- 유지보수
- 책스터디
- 헥사고날아키텍처
- 만들면서배우는클린아키텍처
- FP
- 이펙티브코틀린
- Spring
- Today
- Total
김동형수 개발기
도메인 주도 개발 시작하기 - 1장 본문
1장 도메인 모델 시작하기
도메인이란?
도메인 : 구현해야 할 소프트웨어 대상, 소프트웨어로 해결하고자 하는 문제 영역
도메인은 다시 하위 도메인을 나눌 수 있다.
모든 도메인을 직접 구현해야 하는 것은 아니고 외부 시스템을 이용할 수 있다.
도메인 전문가와 개발자 간 지식 공유
요구사항을 올바르게 이해하려면? 개발자와 전문가가 직접 대화한다.(당연한 이야기..)
이해관계자와 개발자도 도메인 지식을 갖춰야 한다.
도메인 모델 시작하기
기본적으로, 도메인 모델은 특정 도메인을 개념적으로 표현한 것이다.
도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는 데 도움이 된다.
도메인 모델은 객체로만 모델링 할 수 있는 것은 아니고, 다이어그램을 이용해서 상태 전이 모델링을 할 수 있다.
관계가 중요하면 그래프를 이용해서 도메인을 모델링 할 수 있다.
도메인을 이해하는데 도움이 된다면, 표현방식은 중요하지 않다.
도메인 모델 패턴
어플리케이션 아키텍처
표현 / 응용 / 도메인 / 인프라 - DB
도메인 계층은 핵심 규칙을 구현한다.
'주문'을 예를 들어 '출고 전에 배송지를 변경할 수 있다'라는 규칙과 '주문 취소는 배송 전에만 할 수 있다'라는 규칙을 구현한 코드가 도메인 계층에 위치하게 된다.
이런 도메인 규칙을 객체 지향 기법으로 구현하는 패턴이 도메인 모델 패턴이다.
핵심 규칙을 구현한 코드는 도메인 모델에만 위치하기 때문에 규칙이 바뀌거나 규칙을 확장해야 할 때 달느 코드에 영향을 덜 주고 변경 내역을 모델에 반영할 수 있게 된다.
도메인 모델 도출
도메인을 이해하고 이를 바탕으로 도메인 모델 초안을 만들어야 비로소 코드를 작성할 수 있다.
구현을 시작하려면 도메인에 대한 초기 모델이 필요하다.
요구사항 정련을 위해 도메인 전문가나 다른 개발자와 논의하는 과정에서 공유하기도 한다. 모델을 공유할 때는 화이트보드나 위키와 같은 도구를 사용해서 누구나 쉽게 접근할 수 있도록 하면 좋다.
엔티티와 밸류
도출한 모델은 크게 엔티티와 밸류로 구분할 수 있다.
엔티티와 밸류를 제대로 구분해야 도메인을 올바르게 설계하고 구현할 수 있기 때문에 이 둘의 차이를 명확하게 이해하는 것은 도메인을 구현하는 데 있어 중요하다.
밸류 타입은 코드의 의미를 더 잘 이해할 수 있도록 한다.
데이터 변경 기능을 제공하지 않는 타입을 불변(Immutable)이라고 표현한다.
불변 타입의 가장 중요한 이유는 안전한 코드를 작성할 수 있다는 데 있다.
불변 타입의 밸류라면 그림 1.10에 나오는 예제 ( 변수의 오염 / 참조 투명성 ) 같은 상황을 방지하고자 방어코드를 작성할 필요가 없다.
불변 객체는 참조 투명성과 스레드에 안전한 특징을 갖고 있다.
식별자는 단순한 문자열이 아니라 도메인에서 특별한 의미를 지니는 경우가 많기 때문에 식별자를 위한 밸류 타입을 사용해서 의미가 잘 드러나도록 할 수 있다.
도메인 모델에 get/set 메서드를 무조건 추가하는 것은 좋지 않은 버릇이다.
습관적으로 작성한 set메서드는 필드값만 변경하고 끝나기 때문에 상태 변경과 관련된 도메인 지식이 코드에서 사라지게 된다.
set 메서드의 또 다른 문제는 도메인 객체를 생성할 때 온전하지 않은 상태가 될 수 있다.
도메인 객체가 불완전한 상태로 사용되는 것을 막으려면 생성 시점에 필요한 것을 전달해 주어야 한다.
즉 생성자를 통해 필요한 데이터를 모두 받아야 한다.
생성자로 필요한 것을 모두 받으므로 생성자를 호출하는 시점에 필요한 데이터가 올바른지 검사할 수 있다.
set 메서드를 구현해야 할 특별한 이유가 없다면 불변 타입의 장점을 살릴 수 있도록 밸류 타입은 불변으로 구현한다.
도메인 용어와 유비쿼터스 언어
도메인에서 사용하는 용어를 코드에 반영하지 않으면 그 코드는 개발자에게 코드의 의미를 해석해야 하는 부담을 준다.
주문 도메인의 예를 들면,
STEP_1, STEP_2, ... 의 방식보다는 PAYMENT_WATING, PREPARING, ... 으로 바꾸게 되면 코드(STEP_1, STEP_2, ... )를 도메인 용어(PAYMENT_WATING, PREPARING, ... )로 해석하거나 도메인 용어를 코드로 해석하는 과정이 줄어든다.
최대한 도메인 용어를 사용해서 도메인 규칙을 코드로 작성하게 되므로 버그도 줄어든다.
유비쿼터스 언어 - 도메인과 관련된 공통의 언어를 만들고 이를 대화, 문서, 도메인 모델, 코드, 테스트 등 모든 곳에서 같은 용어를 사용한다.
도메인에 대한 이해가 높아지는데 새롭게 이해한 내용을 잘 표현할 수 있는 용어를 찾아내고 이를 다시 공통의 언어로 만들어 다 같이 사용한다. 새로 발견한 용어는 코드나 문서에도 반영해서 산출물에 최신 모델을 적용한다.
도메인 용어는 매우 중요한 요소임에 틀림 없지만, 영어라는 불리한 점이 있다.
알맞은 영단어를 찾는 것은 쉽지 않은 일이지만 시간을 들여 찾는 노력을 해야한다.
도메인 용어에 알맞은 단어를 찾는 시;간을 아까워하지 말자.
'책 스터디 > [완료] DDD - 도메인 주도 개발 시작하기' 카테고리의 다른 글
도메인 주도 개발 시작하기 - 6장 (0) | 2023.04.06 |
---|---|
도메인 주도 개발 시작하기 - 5장 (0) | 2023.03.30 |
도메인 주도 개발 시작하기 - 4장 (0) | 2023.03.23 |
도메인 주도 개발 시작하기 - 3장 (0) | 2023.03.09 |
도메인 주도 개발 시작하기 - 2장 (0) | 2023.03.02 |