책에 대하여

좋은 책이다.

앞 절반은 대체 왜 그렇게 의존성 역전을 강조하는지 의아했고,

뒤 절반은 대체 왜 그렇게 앞에서 한 얘기를 또 하는건지 의아했다.

추가적으로 마지막 34장은 꽤 재밌었다.

결국 남은 거라곤 그놈의 도메인 도메인 도메인 DI DI DI 아이젠하워 아이젠하워 아이젠하워 뿐인데, 그럼에도 불구하고 정말 좋은 책이다.

개인적으로 나는 다음 질문들에 대한 답을 얻었다:

• Service 클래스를 주입받을 수 있는데 왜 Interface 를 사용해야 하는가?
  • Interface 를 쓰면 어떤 (심리적, 물리적) 효용이 있는가?
• 의존성을 '역전'한다는게 대체 무슨 말인가? 그리고 어떻게 하는가?
• 무슨 일을 먼저 해야 하는가?

얻은 교훈에 비해 책장이 조금 많을 수 있다. 하지만 꽤 그럴 가치가 있었다는 주장으로 조심스레 꺼내본다.

사족을 붙이자면, 올해 읽은 모든 책을 통틀어서 '나와 같이 일할 동료가 읽어봤기를 소망하는 책' 부문 1위에 선정하고 싶다.

가장 감명깊게 읽은 부분

34장의 이 부분이 (그 직전 장의 그림과 더불어) 가장 충격적이었다.

아직도 잘 이해가 안되는 부분

스터디원들끼리 여러 차례 얘기를 나눴지만 모두가 만족할만한 결론에 도출하지 못했다.

• 공변성, 반공변성, 무공변성
• (113p 그림 13.1) REP, CCP, CRP 의 개념과 상관관계
• (220p 그림 22.2) InputBoundary와 OutputBoundary의 실체

스터디에 대하여

이 책은 사내 스터디를 통해 진행되었다. 스터디의 방식은 굉장히 독특했으며, 망하지 않는 스터디를 운영하기 위해 온갖 장치들이 동원되었다. 결과적으로 꽤 성공적이었다. 그리고 성공적인 스터디를 위한 가장 크고 필수불가결한 요소인 스터디원이 너무 좋은 분들이었기에 힘겨운 34장의 모험을 끝마칠 수 있었다. 이 지면을 빌려 황 모씨, 강 모씨, 그리고 또 다른 황 모씨에게 심심한 존경의 마음을 실어 보낸다.

아래는 각 팀원이 돌아가며 매주 요약한 클린 아키텍처 각 장의 내용을 다시 한 번 요약한 내용이다:

요약

1장
"일단 급한 피쳐 내고 나중에 다듬어야지" 의 나중 같은건 영원히 오지 않는다. 지금 해야 한다.
2장
긴급하고 중요하지 않은 일보다 급하지 않은데 중요한 일을 더 우선 처리해야 한다.

3장 프로그래밍 패러다임
구조적 프로그래밍
객체 지향 프로그래밍
함수형 프로그래밍
4장 구조적 프로그래밍 패러다임
구조적 프로그래밍은 프로그램을 증명 가능한 세부 기능 집합으로 재귀적으로 분해할 것을 강요하고, 테스트를 통해 증명 가능한 세부 기능들이 거짓인지를 증명하려고 시도한다.

5장 객체 지향 프로그래밍
OOP는 제어흐름을 간접적으로 전환하는 규칙을 부과한다.
6장 함수형 프로그래밍
함수형 언어는 변수가 변경되지 않는다. (불변)

7장 SRP: 단일 책임의 원칙
SRP의 정의: 하나의 모듈은 하나의 엑터 에 대해서만 책임져야한다
8장 OCP: 개방-폐쇄 원칙
OCP를 통해 저수준 컴포넌트로부터 발생한 변경에서 고수준 컴포넌트를 보호할 수 있다.

9장: LSP
아키텍처 레벨에서 LSP 를 위반한다는 것은, 특정 구현체에 종속된다는 뜻.
10장: ISP
아키텍처 레벨에서의 ISP 위반 사례는, '내가 사용하지 않는 모듈의 업데이트 때문에 나까지 재컴파일해야 되는 상황'.

13장 컴포넌트 응집도 : 어느 클래스를 어느 컴포넌트에 포함시켜야 하는가?
14장 컴포넌트 결합: 컴포넌트 사이의 관계에 대한 원칙

15장 아키텍처란?
아키텍처의 주된 목적: 시스템의 생명주기를 지원하는 것
= 시스템을 쉽게 이해, 개발, 유지보수, 배포 가능하도록 해주는 것
16장 독립성
좋은 아키텍처가 지원해야하는 것 -> 유즈케이스, 운영, 개발, 배포

17장 - "유스케이스 (=업무규칙=비즈니스로직) 과 아무 상관없는 결정들을 최대한 늦게 하라"
18장 - "다양한 형태의 경계가 있다. 플러그인 아키텍쳐를 구현하라"

19장 정책과 수준
좋은 아키텍처 : 저수준 컴포넌트 --(의존)--> 고수준 컴포넌트 => 저수준의 변경이 고수준에 영향도를 줄임
20장 업무규칙
핵심 업무 규칙 : 사람이 수동으로 직접 수행하더라도 사업적으로 수익을 얻거나 비용을 줄일 수 있음.

21-22장
프레임워크는 사용하는 도구일 뿐이고, 프레임워크를 포함한 외부 환경/도구는 열어둬야할 선택사항이다.
아키텍쳐는 유스케이스를 지원해야하고, 프레임워크와 거리를 둔다면 테스트하기 쉬워진다.
의존성은 반드시 고수준의 정책을 향해야 한다. (e.g. 프레임워크와 드라이버 → 인터페이스 어댑터 → 유스케이스 → 엔티티)

23장 프레젠터와 험블 객체
험블 객체 패턴을 통해 테스트 쉬운 / 어려운 객체를 분리해서 테스트 용이성을 키울 수 있다
24장 부분적 경계
과도하게 경계를 만드는건 비용이 많이들고 당장 만들기에는 YANGNI 같다면? 부분적 경계를 고려할 수 있다.
25장 계층과 경계
경계는 어디서든 어떻게든 존재할 수 있고, 아키텍트로서 이 경계가 언제 필요한지 신중하게 파악해야한다.

26장 : Main 컴포넌트
메인에서 해야 할 일: 초기 조건, 설정, 외부 자원 세팅, DI 등등.
27장 : '크고 작은 모든' 서비스들
MSA 와 '아키텍처' 사이에 직접적 상관관계는 없다. MSA 는 단지 하나의 배포 방식이다.
28장 : 테스트 경계
테스트는 아키텍처의 외곽에 있다.

29장 클린 임베디드 아키텍처
펌웨어는 얇게
30장 데이터베이스는 세부사항이다
그러하다
31장 웹은 세부사항이다
그러하다

32장
프레임워크와는 결혼하지말고, 연애만 하자.
33장
생략
34장
팀의 규모, 기술 수준, 해결책의 복잡성을 일정과 예산이라는 제약과 동시에 고려하라.

같이 보면 좋을 영상과 글

https://blog.cleancoder.com/uncle-bob/2014/10/01/CleanMicroserviceArchitecture.html