▣ 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 정리