도메인 주도 설계 철저 입문
도서명:도메인 주도 설계 철저 입문
저자/출판사:나루세,마사노부/위키북스
쪽수:376쪽
출판일:2020-10-14
ISBN:9791158392246
목차
▣ 01장: 도메인 주도 설계란?
1.1 도메인 주도 설계란 무엇인가?
1.2 도메인 지식에 초점을 맞춘 설계 기법
___1.2.1 도메인 모델링이란 무엇인가?
___1.2.2 지식을 코드로 나타내는 도메인 객체
1.3 이 책의 접근법과 목표
1.4 이 책에서 설명하는 패턴에 대하여
___1.4.1 지식 표현을 위한 패턴
___1.4.2 애플리케이션을 구성하기 위한 패턴
___1.4.3 지식 표현을 위한 고급 패턴
▣ 02장: 시스템 특유의 값을 나타내기 위한 ‘값 객체’
2.1 값 객체란?
2.2 값의 성질과 값 객체 구현
___2.2.1 값의 불변성
___2.2.2 교환 가능하다
___2.2.3 등가성 비교 가능
2.3 값 객체가 되기 위한 기준
2.4 행동이 정의된 값 객체
___2.4.1 정의되지 않았기 때문에 알 수 있는 것
2.5 값 객체를 도입했을 때의 장점
___2.5.1 표현력의 증가
___2.5.2 무결성의 유지
___2.5.3 잘못된 대입 방지하기
___2.5.4 로직을 한곳에 모아두기
2.6 정리
▣ 03장: 생애주기를 갖는 객체 - 엔티티
3.1 엔티티란?
3.2 엔티티의 성질
___3.2.1 가변이다
___3.2.2 속성이 같아도 구분할 수 있다
___3.2.3 동일성
3.3 엔티티의 판단 기준 - 생애주기와 연속성
3.4 값 객체도 되고 엔티티도 될 수 있는 모델
3.5 도메인 객체를 정의할 때의 장점
___3.5.1 자기 서술적인 코드가 된다
___3.5.2 도메인에 일어난 변경을 코드에 반영하기 쉽다
3.6 정리
▣ 04장: 부자연스러움을 해결하는 도메인 서비스
4.1 서비스란?
4.2 도메인 서비스란?
___4.2.1 값 객체나 엔티티에 정의하기 어색한 행동
___4.2.2 부자연스러움을 해결해주는 객체
4.3 도메인 서비스를 남용한 결과
___4.3.1 도메인 서비스는 가능한 한 피할 것
4.4 엔티티/값 객체와 함께 유스케이스 수립하기
___4.4.1 사용자 엔티티 확인
___4.4.2 사용자 생성 처리 구현
4.5 물류 시스템의 도메인 서비스 예
___4.5.1 거점의 행동으로 정의하기
___4.5.2 운송 도메인 서비스 정의하기
4.6 정리
▣ 05장: 데이터와 관계된 처리를 분리하자 - 리포지토리
5.1 리포지토리란 무엇인가
5.2 리포지토리의 책임
5.3 리포지토리의 인터페이스
5.4 SQL을 이용하는 리포지토리 구현하기
5.5 테스트로 구현 검증하기
___5.5.1 테스트가 필요한 작업 확인하기
___5.5.2 기도하는 자의 테스트 이론
___5.5.3 기도는 이제 그만
5.6 테스트용 리포지토리 만들기
5.7 객체-관계 매핑이 적용된 리포지토리 구현하기
5.8 리포지토리에 정의되는 행동
___5.8.1 객체의 저장과 관계된 행위
___5.8.2 저장된 객체의 복원과 관계된 행위
5.9 정리
▣ 06장: 유스케이스를 구현하기 위한 ‘애플리케이션 서비스’
6.1 애플리케이션 서비스란 무엇인가
6.2 유스케이스 수립하기
___6.2.1 도메인 객체 준비하기
___6.2.2 사용자 등록 처리 구현하기
___6.2.3 사용자 정보 확인 처리 구현하기
___6.2.4 사용자 정보 수정 처리 구현하기
___6.2.5 탈퇴 처리 구현하기
6.3 도메인 규칙의 유출
6.4 애플리케이션 서비스와 프로그램의 응집도.
___6.4.1 응집도가 낮은 애플리케이션 서비스
6.5 애플리케이션 서비스의 인터페이스
6.6 서비스란 무엇인가
___6.6.1 서비스는 무상태다
6.7 정리
▣ 07장: 소프트웨어의 유연성을 위한 의존 관계 제어
7.1 특정 기술 요소에 대한 의존의 결과
7.2 의존이란 무엇인가
7.3 의존 관계 역전 원칙이란 무엇인가
___7.3.1 추상 타입에 의존하라
___7.3.2 주도권을 추상 타입에 둬라
7.4 의존 관계 제어하기
___7.4.1 Service Locator 패턴
___7.4.2 IoC Container 패턴
7.5 정리
▣ 08장: 소프트웨어 시스템 구성하기
8.1 소프트웨어에 꼭 필요한 사용자 인터페이스
8.2 명령행 인터페이스 추가하기
___8.2.1 Main 구현하기
8.3 MVC 프레임워크 적용하기
___8.3.1 의존 관계 설정하기
___8.3.2 컨트롤러 구현하기
8.4 단위 테스트 작성하기
___8.4.1 사용자 등록 처리를 위한 단위 테스트
8.5 정리
▣ 09장: 복잡한 객체 생성을 맡길 수 있는 ‘팩토리 패턴’
9.1 팩토리의 목적
9.2 번호 매기기를 구현한 팩토리의 구현 예
___9.2.1 자동 번호 매기기 기능 활용하기
___9.2.2 번호 매기기 메서드를 리포지토리에 두기
9.3 팩토리 역할을 하는 메서드
9.4 복잡한 객체 생성 절차를 캡슐화하기
9.5 정리
▣ 10장: 데이터의 무결성 유지하기
10.1 무결성이란 무엇인가
10.2 치명적인 버그
10.3 방법 1 - 유일 키 제약
___10.3.1 유일 키 제약에 중복 확인을 맡겼을 경우의 문제점
___10.3.2 유일 키 제약의 올바른 활용
10.4 방법 2 - 트랜잭션
___10.4.1 트랜잭션을 사용하는 패턴
___10.4.2 트랜잭션 범위를 사용하는 패턴
___10.4.3 AOP를 사용하는 패턴
___10.4.4 유닛오브워크를 사용하는 패턴
___10.4.5 트랜잭션으로 인한 로크
10.5 정리
▣ 11장: 애플리케이션 밑바닥부터 만들기
11.1 애플리케이션을 만드는 과정
11.2 어떤 기능을 구현할까
___11.2.1 서클 기능 분석하기
11.3 서클에 대한 지식을 담은 객체 만들기
11.4 유스케이스 구현하기
___11.4.1 말과 어긋나는 코드가 일으킬 수 있는 일
___11.4.2 규칙이 도메인 객체를 이탈했을 때 생기는 일
11.5 정리
▣ 12장: 도메인의 규칙을 지키는 ‘애그리게이트’
12.1 애그리게이트란?
___12.1.1 애그리게이트의 기본 구조
___12.1.2 객체를 다루는 조작의 기본 원칙
___12.1.3 내부 데이터를 숨기기 위해
12.2 애그리게이트의 경계를 어떻게 정할 것인가
___12.2.1 식별자를 이용한 컴포지션
12.3 애그리게이트의 크기와 조작의 단위
12.4 언어 표현과의 모순 제거하기
12.5 정리
▣ 13장: 복잡한 조건을 나타내기 위한 ‘명세’
13.1 명세란?
___13.1.1 객체의 복잡한 평가 절차
___13.1.2 이 문제의 해결책 - 명세
___13.1.3 리포지토리를 되도록 사용하지 않기
13.2 명세와 리포지토리의 조합
___13.2.1 추천 서클 검색 기능으로 본 복잡한 검색
___13.2.2 명세를 이용한 해결책
___13.2.3 명세와 리포지토리를 함께 사용할 때 생기는 성능 문제
___13.2.4 복잡한 쿼리는 리드모델로
13.3 정리
▣ 14장: 아키텍처
14.1 아키텍처의 역할
___14.1.1 안티패턴 - 스마트 UI
___14.1.2 도메인 주도 설계가 아키텍처에게서 원하는 것
14.2 아키텍처
___14.2.1 계층형 아키텍처
___14.2.2 헥사고날 아키텍처
___14.2.3 클린 아키텍처
14.3 정리
▣ 15장: 앞으로의 학습
15.1 경량 DDD에 머무르지 않기 위해
15.2 도메인 전문가와 함께 모델링하기
___15.2.1 해결이 필요한 진짜 문제 찾기
___15.2.2 도메인과 코드를 연결하는 모델
15.3 보편 언어
___15.3.1 깊은 통찰을 얻으려면
___15.3.2 코드에서 사용되는 보편 언어
15.4 컨텍스트의 경계 정하기
15.5 컨텍스트맵
___15.5.1 팀과 팀 사이의 가교 역할을 하는 테스트
15.6 상향식 도메인 주도 설계
15.7 정리
▣ 부록: 솔루션 구성
A.1 소프트웨어 개발의 첫걸음
___A.1.1 도메인 레이어의 패키지 구성
___A.1.2 애플리케이션 레이어의 패키지 구성
___A.1.3 인프라스트럭처 레이어의 패키지 구성
A.2 솔루션 구성
___A.2.1 모두 별도의 프로젝트에 두는 구성
___A.2.2 애플리케이션과 도메인 레이어만 같은 프로젝트에 두는 구성
___A.2.3 특정 언어의 기능이 미치는 영향
A.3 정리
