도메인 주도 설계 철저 입문

코드와 패턴으로 밑바닥부터 이해하는 DDD

이해하기 쉬운 패턴부터 학습하자! 도메인 주도 설계를 쉽게 이해할 수 있는 입문서!

초심자라도 이해하기 쉽고 실천하기도 쉬운 패턴부터 시작해 구체적인 예제와 함께 도메인 주도 설계에서 자주 볼 수 있는 패턴의 목적과 구현 방법을 하나씩 보톰업 방식으로 설명한다.

에릭 에반스의 《도메인 주도 설계》를 읽고 감명받아 쓰게 된 도메인 주도 설계 입문서이며, 앞으로 《도메인 주도 설계》를 읽으려는 독자, 또는 이미 해당 도서를 읽었더라도 ‘더 이해하기 쉬운 입문서’를 필요로 하는 엔지니어를 대상으로 한다.

이 책의 목적은 《도메인 주도 설계》 프랙티스 중에서도 상대적으로 이해하기 쉬운 구현 패턴부터 시작해 《도메인 주도 설계》에 본격적으로 입문하는 것이다. 그런 만큼 구현 패턴을 집중적으로 다룬다. 특히 도메인 주도 설계에서 자주 등장하는 패턴의 구현 방법 및 그 목적을 함께 설명하는 형식을 취하는 것이 특징이다. 이 책에서 설명하는 구현 패턴은 다음과 같다.

◎ [도메인 지식을 나타내기 위한 일반 패턴] 값 객체 / 엔티티 / 도메인서비스

◎ [애플리케이션을 만들기 위한 패턴] 리포지토리 / 애플리케이션서비스 / 팩토리

◎ [도메인 지식을 나타내기 위한 고급 패턴] 애그리게이트 / 명세

나루세 마사노부 (成瀬 允宣)

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

심효섭

연세대학교 문헌정보학과를 졸업하고 모교 중앙도서관과의 인연으로 도서관 솔루션 업체에서 일하면서 개발을 시작했다. 네이버에서 웹 서비스 개발 업무를 맡았으며, 웹 서비스 외에 머신러닝에 대한 공부도 꾸준히 하고 있다. 최근 관심사는 회사에 속하지 않고도 지속 가능한 삶이다. 옮긴 책으로 『Vue.js 철저 입문』 『도커/쿠버네티스를 활용한 컨테이너 개발 실전 입문』 『PyTorch를 활용한 강화학습/심층강화학습 실전 입문』 『PyTorch를 활용한 머신러닝, 딥러닝 철저 입문』 등이 있다.

  • ▣ 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 정리
  • 24쪽, 리스트 2-24의 3~4번째 줄

    private readonly FirstName firstName;
    private readonly LastName lastName;
    

    ==>

    private readonly string firstName;
    private readonly string lastName;
    
  • 36쪽, 리스트 2-36을 아래 내용으로 교체

    var userName = "me";
    
  • 37쪽, 본문 마지막 문장

    리스트 3-29에 실린 간단한 대입문을 예로 들어보자.

    ==>

    리스트 2-39에 실린 간단한 대입문을 예로 들어보자.

  • 51쪽, 리스트 3-4의 18번째 줄

    public User(string name)
    

    ==>

    public User(UserId id, string name)
    
  • 53쪽, 리스트 3-5의 6번째 줄

    public User(string name)
    

    ==>

    public User(UserId id, string name)
    
  • 154쪽, 그림 7-6을 다음 그림으로 교체

    ddd-7.6.png