[출판사서평]
객체지향 시스템, 제대로 디자인하라!
6가지 원칙 & 실용적인 접근 방식을 배우자!

객체지향 디자인, 단순하게 유지하자!
개발자의 작업 대부분은 기존 시스템을 유지하고 발전시키는 것이다. 유지보수성이 높은 소프트웨어 시스템을 구축하려면 좋은 객체지향 디자인이 필요하며, 좋은 객체지향 디자인의 핵심 요소는 단순함이다. 처음에 시스템을 잘 디자인했다 하더라도 수정할 때마다 복잡성이 증가한다. 새로운 클래스, 메서드, 기능이 추가될 때마다 관리해야 할 상태와 추상화가 늘어난다. 자연스러운 복잡성 증가에 맞서 디자인을 단순하게 유지하는 건 어려운 일이지만, 복잡성 관리는 소프트웨어 시스템을 효과적으로 유지하고 발전시키는 데 필수적인 과정이다. 복잡성을 제어하고, 객체지향 디자인을 단순하게 유지할 수 있도록 도와주는 6가지 디자인 원칙에 대해 알아보자.

명확하고 실용적인 6가지 원칙을 깊이 탐구하자!
객체지향 코드베이스가 성장하고 변화하더라도 단순하게 유지할 수 있는 실용적인 설계 원칙이자, 모든 객체지향 언어에 적용할 수 있는 실용적인 기법을 모았다. 그 원칙을 다음 6가지 측면으로 나눠 하나씩 깊이 탐구할 것이다. 각 원리를 더욱 깊이 있게 이해할 수 있도록 쉬운 그림, 실제와 같은 시스템 예제, 생각해볼 수 있는 연습 문제를 준비했다.

코드를 작게 유지하는 방법
객체의 일관성을 유지하는 방법
의존성을 적절하게 관리하는 방법
추상화를 이해하고 잘 디자인하는 방법
인프라를 올바르게 처리하고 다루는 방법
잘 모듈화된 디자인을 달성하는 방법

실무적인 관점으로 백엔드 시스템 예제를 살펴보자!
각 원칙의 개념을 먼저 설명한 뒤 이 원칙을 어떻게 적용하는지 코드 예제를 통해 실무적인 관점에서 설명한다. 디자인 패턴을 설명하기 위해 이 책 전반에 걸쳐 피플그로우!라는 가상의 백엔드 시스템 예제를 사용할 것이다. 피플그로우!를 구축하는 팀은 현재 유지보수 문제에 직면해 있다. 버그가 발생하고, 간단한 변경이 시스템의 예기치 않은 영역에 영향을 미쳐 변경 사항을 완료하는 데 며칠씩 걸린다. 피플그로우!의 디자인 결정을 자세히 알아보고 이를 개선하면서 각 원칙의 맥락, 장단점, 원칙을 적용해야 할 때와 말아야 할 때도 함께 알아볼 것이다.

[목차]
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 null은 신중하게 사용하고, 피할 수 있다면 피하라
__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 요약

찾아보기