1장 모든 게 복잡도 관리다
1.1 객체지향 디자인과 시간이 주는 시련
1.2 단순한 객체지향 시스템 디자인
__1.2.1 단순한 코드
__1.2.2 일관성 있는 객체
__1.2.3 적절한 의존성 관리
__1.2.4 좋은 추상화
__1.2.5 외부 의존성과 인프라 적절히 다루기
__1.2.6 좋은 모듈화
1.3 일상적인 활동으로서의 단순한 디자인
__1.3.1 복잡성 줄이기는 개인 위생과 비슷하다
__1.3.2 복잡성이 필요할 수도 있지만 영구적이어서는 안 된다
__1.3.3 지속적으로 복잡성을 해결하는 것이 비용 효율적이다
__1.3.4 고품질 코드는 좋은 실무 프랙티스를 촉진한다
__1.3.5 복잡성을 통제하는 것은 생각보다 어렵지 않다
__1.3.6 디자인을 단순하게 유지하는 것은 개발자의 책임이다
__1.3.7 이 정도면 충분히 좋은 디자인이다
1.4 정보 시스템의 아키텍처에 대해 간략히 살펴보기
1.5 예제: 피플그로우!
1.6 연습문제
1.7 요약


2장 코드를 작게 유지하기
2.1 코드 단위를 작게 만들라
__2.1.1 복잡한 메서드를 비공개 메서드로 나눠라
__2.1.2 복잡한 코드 단위를 다른 클래스로 옮겨라
__2.1.3 코드를 작은 단위로 나누지 말아야 할 때
__2.1.4 리팩터링하기 전에 전체적으로 살펴보라
__2.1.5 예제: 직원 데이터 임포트하기
2.2 코드를 읽기 쉽게 만들고 문서화하라
__2.2.1 좋은 이름을 계속 찾아라
__2.2.2 의사결정을 문서화하라
__2.2.3 코드에 주석을 추가하라
__2.2.4 예제: 오퍼링 내용 변경 안내 이메일을 언제 발송할지 결정하기
2.3 새로운 복잡성을 기존 클래스에서 분리하라
__2.3.1 복잡한 비즈니스 로직을 자체 클래스로 분리하라
__2.3.2 큰 비즈니스 흐름을 분해하라
__2.3.3 예제: 오퍼링에 대한 대기자 명단
2.4 연습문제
2.5 요약


3장 객체의 일관성 유지하기
3.1 항상 일관성을 유지하라
__3.1.1 클래스가 스스로 일관성을 책임지게 하라
__3.1.2 전체 작업과 복잡한 일관성 검사를 캡슐화하라
__3.1.3 예제: Employee 엔터티
3.2 효과적인 데이터 유효성 검사 메커니즘을 디자인하라
__3.2.1 사전 조건을 명시적으로 정의하라
__3.2.2 유효성 검증 컴포넌트를 만들라
__3.2.3 %00;은 신중하게 사용하고, 피할 수 있다면 피하라
__3.2.4 예제: 교육 과정에 직원 추가하기
3.3 상태 확인을 캡슐화하라
__3.3.1 명령하라, 질문하지 마라
__3.3.2 예제: 오퍼링의 빈 자리 확인
3.4 필요한 게터와 세터만 제공하라
__3.4.1 상태를 변경하지 않고 클라이언트에 너무 많은 정보를 노출하지 않는 게터
__3.4.2 세터는 객체를 설명하는 속성에만 사용한다
__3.4.3 예제: Offering 클래스의 게터와 세터
3.5 객체 집단의 불변 조건을 보장하도록 애그리게이트를 모델링하라
__3.5.1 애그리게이트 루트의 규칙을 깨지 마라
__3.5.2 예제: Offering 애그리게이트
3.6 연습문제
3.7 요약


4장 의존성 관리하기
4.1 고수준 코드와 저수준 코드를 분리하라
__4.1.1 안정적인 코드를 디자인하라
__4.1.2 인터페이스 발견 098
__4.1.3 고수준 코드와 저수준 코드를 분리하지 않아도 되는 경우
__4.1.4 예제: 메시지 처리 작업
4.2 불필요한 세부 사항이나 요소에 의존하는 것을 피하라
__4.2.1 여러분이 소유한 클래스만 요구하거나 반환하라
__4.2.2 예제: HTTP 봇을 채팅 SDK로 대체하기
__4.2.3 클라이언트에게 필요한 것 이상을 제공하지 마라
__4.2.4 예제: 오퍼링 목록
4.3 너무 많은 클래스에 의존하는 클래스를 분리하라
__4.3.1 예제: MessageSender 서비스 분리하기
4.4 의존성을 주입하라(의존성 주입을 사용하라)
__4.4.1 상태를 변경하는 작업에 정적 메서드를 사용하지 마라
__4.4.2 항상 협력자를 주입하라: 그 외에는 원하는 대로 하라
__4.4.3 클래스와 의존성을 함께 생성하는 전략
__4.4.4 예제: MessageSender와 협력자들의 의존성 주입
4.5 연습문제
4.6 요약


5장 추상화 잘 디자인하기
5.1 추상화와 확장 지점을 디자인하라
__5.1.1 추상화의 필요성 식별하기
__5.1.2 확장 지점 디자인하기
__5.1.3 좋은 추상화의 속성
__5.1.4 추상화에서 배워라
__5.1.5 추상화에 대해 배워라
__5.1.6 추상화와 결합
__5.1.7 예제: 직원에게 배지 수여하기
5.2 중요한 비즈니스 규칙을 일반화하라
__5.2.1 일반화된 비즈니스 규칙과 구체적인 데이터를 분리하라
__5.2.2 예제: 배지 규칙 일반화하기
5.3 단순한 추상화를 선호하라
__5.3.1 경험적 규칙
__5.3.2 단순한 것이 항상 더 낫다
__5.3.3 이쯤 되면 추상화를 고려해야 한다
__5.3.4 처음부터 추상화를 모델링하는 것을 두려워하지 마라
__5.3.5 예제: 배지 예제 다시 보기
5.4 연습문제
5.5 요약


6장 외부 의존성과 인프라 다루기
6.1 도메인 코드와 인프라를 분리하라
__6.1.1 인터페이스가 필요한가?
__6.1.2 코드에서는 세부 사항을 숨기고, 개발자에게는 숨기지 마라
__6.1.3 인프라 변경하기: 괜한 걱정일까, 실제로 일어날까?
__6.1.4 예제: 데이터베이스 접근과 메시지 봇
6.2 인프라를 최대한 활용하라
__6.2.1 디자인을 망가뜨리지 않도록 최선을 다하라
__6.2.2 예제: 등록 취소하기
6.3 자신이 소유한 것에만 의존하라
__6.3.1 프레임워크와 싸우지 마라
__6.3.2 간접 누출에 주의하라
__6.3.3 예제: 메시지 봇
6.4 저수준 인프라 오류를 고수준 도메인 오류로 캡슐화하라
__6.4.1 예제: SDKBot의 예외 처리
6.5 연습문제
6.6 요약


7장 모듈화 달성하기
7.1 깊이 있는 모듈을 구축하라
__7.1.1 변경의 영향을 줄이는 방법을 찾아라
__7.1.2 도메인 경계를 지속적으로 다듬어라
__7.1.3 관련된 항목을 가까이 유지하라
__7.1.4 우발적인 결합을 피하되, 불가피하다면 문서로 남겨라
7.2 인터페이스를 명확히 디자인하라
__7.2.1 모듈의 인터페이스를 단순하게 유지하라
__7.2.2 하위 호환성을 갖춘 모듈
__7.2.3 깔끔한 확장 지점을 제공하라
__7.2.4 다른 요구 사항을 가진 사람들이 모듈을 사용하는 것처럼 코딩하라
__7.2.5 모듈은 명확한 소유권과 참여 규칙이 있어야 한다
7.3 모듈 간의 친밀성을 피하라
__7.3.1 모듈과 클라이언트가 친밀성을 없애는 것을 책임지게 하라
__7.3.2 내부 클래스에 의존하지 마라
__7.3.3 의존성의 거미줄을 모니터링하라
__7.3.4 모놀리스인가, 마이크로서비스인가?
__7.3.5 모듈을 분리하는 방법으로 이벤트를 고려하라
__7.3.6 예제: 알림 시스템
7.4 연습문제
7.5 요약


8장 실용적인 접근법
8.1 실용적으로 접근하되, 딱 필요한 만큼만
8.2 과감하게 리팩터링하되, 단 작은 단위로 나눠서
8.3 코드가 완벽하지 않다는 사실을 받아들여라
8.4 재디자인을 고려하라
8.5 여러분은 주니어 개발자들에 대한 책임이 있다
8.6 참고 문헌
8.7 연습문제
8.8 요약