도메인 주도 설계 철저 입문(위키북스 IT Leaders 시리즈 31)

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

나루세 마사노부 成? 允宣

기후현 출신. 프로그래머. 25세에 프로그래밍을 시작했다. 업무 시스템 개발부터 프로그래밍 커리어를 시작해, 게임, 웹 등 다양한 애플리케이션 개발에 종사했다.