소프트웨어의 복잡성을 다스려라!

소프트웨어의 복잡성은 도메인에서 기인하고, 그러한 복잡성을 어떻게 다루느냐가 프로젝트의 성패를 좌우한다. 도메인 주도 설계(Domain-Driven Design)는 복잡한 요건을 지닌 소프트웨어를 개발하는 접근법의 하나다. 도메인 주도 설계에서는 소프트웨어 프로젝트가 핵심 도메인과 도메인 로직에 집중하고, 복잡한 설계는 모델을 기반으로 해야 한다는 전제에서 출발해 유용한 소프트웨어를 개발하는 험난한 여정에서 중요한 설계 결정이나 전략적 사고와 안목이 필요할 때마다 구심점 역할을 할 것이다.

저자인 에릭 에반스의 오랜 경험과 통찰력이 빠짐없이 담긴 『도메인 주도 설계』는 복잡한 소프트웨어를 개발하는 프로젝트에서 의사결정의 기반이 되는 틀과 설계 논의에 사용할 수 있는 어휘를 제공한다. 단순히 설계나 프로세스에 관한 책을 너머 『도메인 주도 설계』는 그 이상의 실용적이고 합리적인 접근법과 설계 및 모델링 기법, 우수 실천법을 독자에게 제시한다. 『도메인 주도 설계』는 비단 소프트웨어 개발자만이 아니라 소프트웨어 프로젝트에 참여하는 모든 이들이 복잡성이라는 도전과제를 다스려서 소프트웨어 프로젝트를 올바른 길로 이끌어 나가는 데 도움될 것이다.

소프트웨어 개발 커뮤니티에서는 도메인 모델링이 소프트웨어 설계에서 중심적인 요소라는 사실을 널리 인정받고 있다. 도메인 모델을 토대로 소프트웨어 개발자들은 풍부한 기능성을 표현하고 그것을 사용자의 진정한 욕구를 충족하는 소프트웨어 구현으로 바꿀 수 있다. 하지만 도메인 모델이 중요하다는 사실이 분명함에도 효과적인 도메인 모델링을 소프트웨어 개발 프로세스에 통합하는 방법을 설명하는 실용적인 참고 자료는 거의 없다.

『도메인 주도 설계』는 그러한 요구를 채워준다. 이 책은 특정 기술에 관한 책이 아니다. 이 책에서는 독자에게 도메인 주도 설계에 대한 체계적인 접근법을 제공하고 폭넓은 우수 설계 실천법과 경험을 토대로 한 기법, 복잡한 도메인에 직면한 소프트웨어 프로젝트의 발전을 가능하게 하는 근본 원칙을 제시한다. 설계 및 개발 원칙들이 한데 어우러져 있는 이 책에서는 현실세계의 소프트웨어 개발에 도메인 주도 설계를 응용한 모습을 생생하게 보여주는 실제 프로젝트에 기반한 수많은 예제가 실려 있다.

독자는 도메인 모델을 활용해 복잡한 개발 노력을 좀더 집중하고 활기를 띠게 만드는 방법을 배울 수 있다. 우수 실천법과 표준 패턴의 핵심은 개발팀을 위한 공통 언어를 제공한다. 애자일 개발의 빈번한 반복주기를 비롯해 단순히 코드가 아니라 코드의 기저에 자리잡은 모델을 리팩터링하는 것에 중점을 둠으로써 도메인에 대한 더 심층적인 통찰력과 도메인 전문가와 프로그래머 사이의 더 나은 의사소통이 가능해진다. 『도메인 주도 설계』는 이를 기반으로 복잡한 시스템과 더 규모가 큰 조직을 위한 모델링과 설계를 다룬다. 이 책에서 다루는 내용

  • 모든 팀원이 동일한 언어를 구사하게 하는 법
  • 모델과 구현의 연계 강화
  • 모델 내에서의 핵심 구분법 연마
  • 도메인 객체의 생명주기 관리
  • 정교한 방법으로 안전하게 조합할 수 있는 도메인 코드 작성
  • 복잡한 개념을 분명하고 예측 가능하게 만들기
  • 도메인 비전 선언문의 공식화
  • 복잡한 도메인의 정수 추출
  • 모델에 필요한 암시적 개념 규명
  • 분석 패턴의 적용
  • 디자인 패턴과 모델의 연결
  • 대규모 시스템에서의 모델의 무결성 유지
  • 동일 프로젝트에 공존하는 모델 다루기
  • 큰 규모 구조를 내포한 시스템의 조직화
  • 모델링 도약의 인식과 대응

이 책을 통해 객체지향 개발자, 시스템 분석가, 설계자들은 자신의 업무를 체계화하고 거기에 집중하는 데 필요한 지침을 얻고, 풍부하고 유용한 도메인 모델을 구축하며, 이러한 모델을 활용해 고품질의 장기적으로 지속되는 소프트웨어 구현을 만들어낼 수 있다.

에릭 에반스 (Eric Evans)

에릭 에반스는 Domain Language의 설립자로서, Domain Language는 회사 업무와 긴밀하게 연계되어 발전하는 소프트웨어의 구축에 헌신하는 컨설팅 조직이다. 그는 1980년대부터 수많은 복잡한 업무 및 기술 도메인에서 대형 객체지향 시스템의 설계자이자 프로그래머로 활동했으며, 익스트림 프로그래밍 개발 방법론을 채택한 개발팀을 대상으로 교육하고 지도해왔다.

이대엽

현재 책 만드는 일을 하고 있으며, 이따금 IT 관련 서적을 번역하기도 한다. 좋은 책을 펴내거나 직접 우리말로 옮겨 독자에게 전하는 데 큰 즐거움을 느끼며, 옮긴 책으로 『이거 불법아냐?』, 『자율학습! 안드로이드 프로그래밍』, 『하이버네이트 완벽 가이드』, 『개념을 잡아주는 프로그래밍 정석』이 있다.

 

옮긴이 글

소프트웨어의 존재 가치는 어디에 있는가? 순수하게 기술적인 분야가 아니라면 아마 특정 업무 분야의 문제를 해결하는 데 있을 것이다. 아무리 기술적으로 정교하고 뛰어난 기능성을 갖추더라도 당면한 문제를 해결하지 못하는 소프트웨어는 실패한 소프트웨어에 지나지 않는다. 어찌 보면 너무나 상식적인 얘기로 들릴지도 모르지만 소프트웨어 업계에 종사하는 개발자들은 기술적인 쟁점에 관심을 보이고 거기에 집중하는 경향이 있다.

『도메인 주도 설계』는 소프트웨어의 핵심에 놓인 복잡성을 다루는 패턴과 기법, 원칙이 담긴 책이다. 이 책은 결국 그러한 복잡성의 출발점인 도메인 자체에 초점을 맞춰, 도메인을 표현한 모델과 설계 사이의 간극을 좁히는 데 집중한다. 저자인 에릭 에반스는 그동안 자신이 여기에 중점을 두고 발견한 통찰력과 체계적으로 정리한 지식을 자신의 경험담을 곁들여 담담한 어조로 풀어낸다.

이 책은 단순히 특정 기술이나 방법론만을 다루는 책이 아니다. 그래서 여기서 소개하는 특정 패턴이나 기법을 일률적으로 적용하거나 쓴다고 해서 도메인 주도 설계를 적용한 프로젝트가 되는 건 아니다. 이 책을 소프트웨어 설계나 개발 방법론을 다룬 책으로 예상하고 접한 독자라면 여기에 담긴 사상이나 철학에 놀랄지도 모르겠다. 『도메인 주도 설계』는 제목에 나온 ‘설계’만이 아니라 그것을 넘어서는 통찰력을 독자에게 제시하고, 소프트웨어 개발에 임하는 자세를 고칠 것을 넌지시 요구할 것이다.

이 책에서 다루는 내용을 모든 소프트웨어 프로젝트에 적용할 수 있는 것은 아니다. 이 책의 부제에 나와 있듯이 대단히 복잡한 도메인에서 사용되는 소프트웨어를 개발하는 프로젝트가 이 책의 내용을 적용하기에 적격이다. 하지만 여기에 담긴 철학과 사상은 어떤 분야에서든, 독자가 누구이든 빛을 발할 것이다. 국내 소프트웨어 개발 현장에도 자신이 종사하는 분야를 진지하게 생각하고 거기에 매진하는 풍토가 조성되고, 비단 개발자만이 아니라 프로젝트를 둘러싼 모든 이해관계자가 소프트웨어 개발에 올바른 시각과 합리적인 태도를 견지하는 데 이 복음서 같은 책이 조금이나마 도움되길 바란다.

  • 01부 동작하는 도메인 모델 만들기
    • 도메인 주도 설계에서의 모델의 유용성
    • 소프트웨어의 본질
    •  
    • 01장 지식 탐구
      • 효과적인 모델링의 요소
      • 지식 탐구
      • 지속적인 학습
      • 지식이 풍부한 설계
      • 심층 모델
      •  
    • 02장 의사소통과 언어 사용
      • UBIQUITOUS LANGUAGE (유비쿼터스 언어)
      • 크게 소리내어 모델링하기
      • 한 팀, 한 언어
      • 문서와 다이어그램
        • 글로 쓴 설계 문서
        • 실행 가능한 기반
      • 설명을 위한 모델
      •  
    • 03장 모델과 구현의 연계
      • MODEL-DRIVEN DESIGN (모델 주도 설계)
      • 모델링 패러다임과 도구 지원
      • 내부 드러내기: 왜 모델이 사용자에게 중요한가
      • HANDS-ON MODELER (실천적 모델러)
      •  
  • 02부 모델 주도 설계의 기본 요소
    • 04장 도메인의 격리
      • LAYERED ARCHITECTURE (계층형 아키텍처)
        • 계층 간 관계 설정
        • 아키텍처 프레임워크
      • 도메인 계층은 모델이 살아가는 곳
      • SMART UI(지능형 UI) “안티 패턴”
      • 다른 종류의 격리
      •  
    • 05장 소프트웨어에서 표현되는 모델
      • 연관관계
      • ENTITY (엔티티, 참조객체라고도 함)
        • ENTITY 모델링
        • 식별 연산의 설계
      • VALUE OBJECT (값 객체)
        • VALUE OBJECT의 설계
        • VALUE OBJECT를 포함한 연관관계 설계
      • SERVICE(서비스)
        • SERVICE와 격리된 도메인 계층
        • 구성 단위
        • SERVICE에 접근하기
      • MODULE(모듈, 패키지라고도 함)
        • 기민한 MODULE
        • 인프라스트럭처 주도 패키지화의 함정
      • 모델링 패러다임
        • 객체 패러다임이 지배적인 이유
        • 객체 세계에서 객체가 아닌 것들
        • 패러다임이 혼재할 때 MODEL-DRIVEN DESIGN 고수하기
      •  
    • 06장 도메인 객체의 생명주기
      • AGGREGATE (집합)
      • FACTORY (팩터리)
        • FACTORY와 FACTORY의 위치 선정
        • 생성자만으로 충분한 경우
        • 인터페이스 설계
        • 불변식 로직의 위치
        • ENTITY FACTORY와 VALUE OBJECT FACTORY
        • 저장된 객체의 재구성
      • REPOSITORY (리파지터리)
        • REPOSITORY에 질의하기
        • 클라이언트 코드가 REPOSITORY 구현을 무시한다 (개발자는 그렇지 않지만)
        • REPOSITORY 구현
        • 프레임워크의 활용
        • FACTORY와의 관계
      • 관계형 데이터베이스를 위한 객체 설계
      •  
    • 07장 언어의 사용(확장 예제)
      • 화물 해운 시스템 소개
      • 도메인 격리: 응용 기능 소개
      • ENTITY와 VALUE OBJECT의 구분
        • 역할과 그 밖의 속성
      • 해운 도메인의 연관관계 설계
      • AGGREGATE의 경계
      • REPOSITORY의 선정
      • 시나리오 연습
        • 예제 애플리케이션 기능: 화물의 목적지 변경
        • 예제 애플리케이션 기능: 반복 업무
      • 객체 생성
        • Cargo에 대한 FACTORY와 생성자
        • Handling Event 추가
      • 리팩터링할 시간: Cargo AGGREGATE의 설계 대안
      • 해운 모델의 MODULE
      • 새로운 기능 도입: 할당량 검사
        • 두 시스템의 연계
        • 모델 강화: 업무 분야 나누기
      • 성능 최적화
      • 최종 검토
      •  
  • 03부 더 심층적인 통찰력을 향한 리팩터링
    • 리팩터링 수준
    • 심층 모델
    • 심층 모델/유연한 설계
    • 발견 과정
      •  
    • 08장 도약
      • 도약에 관한 일화
        • 괜찮은 모델이기는 하지만……
        • 도약
        • 더 심층적인 모델
        • 냉정한 결정
        • 결말
      • 기회
      • 기본에 집중하라
      • 후기 : 연이은 새로운 통찰력의 출현
      •  
    • 09장 암시적인 개념을 명확하게
      • 개념 파헤치기
        • 언어에 귀 기울여라
        • 어색한 부분을 조사하라
        • 모순점에 대해 깊이 고민하라
        • 서적을 참고하라
        • 시도하고 또 시도하라
      • 다소 불명확한 개념의 모델링
        • 명시적인 제약조건
        • 도메인 객체로서의 프로세스
      • SPECIFICATION(명세)
        • SPECIFICATION의 적용과 구현
      •  
    • 10장 유연한 설계
      • INTENTION-REVEALING INTERFACE (의도를 드러내는 인터페이스)
      • SIDE -EFFECT-FREE FUNCTION (부수효과가 없는 함수)
      • ASSERTION (단정)
      • CONCEPTUAL CONTOUR (개념적 윤곽)
      • STANDALONE CLASS (독립형 클래스)
      • CLOSURE OF OPERATION (연산의 닫힘)
      • 선언적 설계
        • 도메인 특화 언어
      • 선언적인 형식의 설계
        • SPECIFICATION을 선언적인 형식으로 확장하기
      • 받음각
        • 서브 도메인으로 분할하라
        • 가능하다면 정립된 정형화를 활용하라
      •  
    • 11장 분석 패턴의 적용
    • 12장 모델과 디자인 패턴의 연결
      • STRATEGY (POLICY라고도 함)
      • COMPOSITE (복합체)
      • 그렇다면 FLYWEIGHT는?
      •  
    • 13장 더 심층적인 통찰력을 향한 리팩터링
      • 시작
      • 조사팀
      • 선행 기술
      • 개발자를 위한 설계
      • 타이밍
      • 위기를 기회로
      •  
  • 04부 전략적 설계
    • 14장 모델의 무결성 유지
      • BOUNDED CONTEXT (제한된 컨텍스트)
        • BOUNDED CONTEXT 안의 균열 인식
      • CONTINUOUS INTEGRATION (지속적인 통합)
      • CONTEXT MAP (컨텍스트 맵)
        • CONTEXT 경계에서의 테스트
        • CONTEXT MAP의 조직화와 문서화
      • BOUNDED CONTEXT 간의 관계
      • SHARED KERNEL (공유 커널)
      • CUSTOMER/SUPPLIER DEVELOPMENTTEAM (고객/공급자 개발 팀)
      • CONFORMIST (준수자)
      • ANTICORRUPTION LAYER (오류 방지 계층)
        • ANTICORRUPTION LAYER의 인터페이스 설계
        • ANTICORRUPTION LAYER의 구현
        • 교훈적인 이야기
      • SEPARATE WAYS (각자의 길)
      • OPEN HOST SERVICE (공개 호스트 서비스)
      • PUBLISHED LANGUAGE (공표된 언어)
      • 코끼리 통일하기
      • 모델의 컨텍스트 전략 선택
        • 팀 의사결정 또는 그 이상
        • 우리 자신을 컨텍스트에 배치하기
        • 경계의 변형
        • 변경할 수 없다는 사실을 인정하기: 외부 시스템의 묘사
        • 외부 시스템과의 관계
        • 설계 중인 시스템
        • 개별 모델의 특수한 요구사항 충족하기
        • 배치
        • 타협점
        • 프로젝트가 이미 진행 중일 때
      • 변형
        • CONTEXT 병합: SEPARATE WAYS → SHARED KERNEL
        • CONTEXT 병합: SHARED KERNEL → CONTINUOUS INTEGRATION
        • 레거시 시스템의 단계적 폐기
        • OPEN HOST SERVICE → PUBLISHED LANGUAGE
      •  
    • 15장 디스틸레이션
      • CORE DOMAIN (핵심 도메인)
        • CORE 선택
        • 누가 그 일을 할 것인가?
      • 디스틸레이션의 단계적 확대
      • GENERIC SUBDOMAIN (일반 하위 도메인)
        • 일반화가 재사용 가능하다는 의미는 아니다
        • 프로젝트 위험 관리
      • DOMAIN VISION STATEMENT (도메인 비전 선언문)
      • HIGHLIGHTED CORE (강조된 핵심)
        • 디스틸레이션 문서
        • 표시된 CORE
        • 프로세스 도구로서의 디스틸레이션 문서
      • COHESIVE MECHANISM (응집력 있는 메커니즘)
        • GENERIC SUBDOMAIN과 COHESIVE MECHANISM
        • MECHANISM이 CORE DOMAIN의 일부인 경우
      • 선언적 형식의 디스틸레이션
      • SEGREGATED CORE (분리된 핵심)
        • SEGREGATED CORE를 만드는 데 드는 비용
        • 발전하는 팀의 의사결정
      • ABSTRACT CORE (추상화된 핵심)
      • 심층 모델의 디스틸레이션
      • 리팩터링의 대상 선택
      •  
    • 16장 대규모 구조
      • EVOLVING ORDER (발전하는 질서)
      • SYSTEM METAPHOR (시스템 은유)
        • “미숙한 은유”와 그것이 필요 없는 이유
      • RESPONSIBILITY LAYER (책임 계층)
        • 적절한 계층의 선택
      • KNOWLEDGE LEVEL (지식 수준)
      • PLUGGABLE COMPONENT FRAMEWORK (착탈식 컴포넌트 프레임워크)
      • 구조는 얼마나 제약성을 지녀야 하는가?
      • 잘 맞아떨어지는 구조를 향한 리팩터링
        • 최소주의
        • 의사소통과 자기 훈련
        • 재구조화가 유연한 설계를 낳는다
        • 디스틸레이션은 부하를 줄인다
      •  
    • 17장 전략의 종합
      • 대규모 구조와 BOUNDED CONTEXT와의 결합
      • 대규모 구조와 디스틸레이션과의 결합
      • 평가 먼저
      • 누가 전략을 세우는가?
        • 애플리케이션 개발에서 창발하는 구조
        • 고객(애플리케이션 개발팀) 중심의 아키텍처 팀
      • 전략적 설계 결정을 위한 6가지 필수 요소
        • 기술 프레임워크도 마찬가지다
        • 종합계획을 조심하라
      •  
  • 결론
    • 맺음말
    • 앞을 내다보며
    •  
  • 부록 이 책에 포함된 패턴의 사용법
    • 패턴 이름
    • 용어 설명
    • 참고 문헌
    • 사진 협찬
  • 26쪽, 두 번째 단락 마지막 줄

    더욱 원할하게 --> 더욱 원활하게

  • 135쪽, 그림 6-6의 왼쪽 그림

    허용한도 : $1000.00

    ==>

    허용한도 : $1,000.00

도서 소개자료