[목 차]
옮긴이 머리말 xi
베타리더 후기 xiii
이 책에 쏟아진 찬사 xv
추천 서문(레베카 J. 워프스브록) xvii
추천 서문(켄트 벡) xviii
머리말 xx
감사의 글 xxv
들어가며 xxvi
PART I 결합
CHAPTER 1 결합과 시스템 설계 3
1.1 결합이란 무엇인가? 4
1.2 결합의 규모 4
1.3 지식의 흐름 7
1.4 시스템 8
1.5 요점 13
1.6 복습 문제 14
CHAPTER 2 결합과 복잡성: 커네빈 17
2.1 복잡성이란 무엇인가? 17
2.2 커네빈 19
2.3 커네빈 도메인의 비교 24
2.4 소프트웨어 설계에서의 커네빈 25
2.5 커네빈 애플리케이션 29
2.6 커네빈과 복잡성 30
2.7 요점 30
2.8 복습 문제 31
CHAPTER 3 결합과 복잡성: 상호작용 33
3.1 복잡성의 본성 34
3.2 복잡성과 시스템 설계 34
3.3 계층적 복잡성 37
3.4 자유도 41
3.5 복잡성과 제약 44
3.6 결합과 복잡한 상호작용 45
3.7 예제: 결합과 복잡성을 연결하기 45
3.8 요점 51
3.9 복습 문제 52
CHAPTER 4 결합과 모듈성 55
4.1 모듈성 56
4.2 모듈 57
4.3 소프트웨어 시스템에서의 모듈성 60
4.4 모듈성, 복잡성, 결합 66
4.5 모듈성에서의 결합 71
4.6 요점 72
4.7 복습 문제 7
PART II 차원
CHAPTER 5 구조적 설계의 모듈 결합 77
5.1 구조적 설계 78
5.2 모듈 결합 78
5.3 모듈 결합 수준 비교하기 91
5.4 요점 92
5.5 복습 문제 93
CHAPTER 6 공생성 95
6.1 공생성이란 무엇인가? 96
6.2 정적 공생성 96
6.3 동적 공생성 102
6.4 공생성 평가하기 108
6.5 요점 111
6.6 복습 문제 112
CHAPTER 7 통합 강도 115
7.1 결합의 강도 116
7.2 통합 강도 118
7.3 침입 결합 119
7.4 기능 결합 122
7.5 모델 결합 125
7.6 계약 결합 130
7.7 통합 강도 논의 138
7.7.1 예제: 분산 시스템 139
7.8 통합 강도와 비동기 실행 140
7.9 요점 142
7.10 복습 문제 142
CHAPTER 8 거리 145
8.1 거리와 캡슐화 경계 145
8.2 거리에 영향을 추는 추가 요인 151
8.3 거리 대 근접성 154
8.4 거리 대 통합 강도 155
8.5 요점 155
8.6 복습 문제 156
CHAPTER 9 변동성 159
9.1 변화와 결합 160
9.2 왜 소프트웨어는 바뀌는가? 161
9.3 변경률 평가하기 163
9.4 변동성과 결합 강도 169
9.5 추론된 변동성 171
9.6 요점 172
9.7 복습 문제 172
PART III 균형
CHAPTER 10 결합 균형 177
10.1 결합 차원 조합하기 178
10.2 강도, 거리, 변동성을 조합하기 183
10.3 숫자 척도로 결합 균형 잡기 186
10.4 요점 192
10.5 복습 문제 193
CHAPTER 11 결합 재조정 195
11.1 탄력적 설계 196
11.2 소프트웨어 변경 벡터 196
11.3 결합 재조정 200
11.4 요점 207
11.5 복습 문제 207
CHAPTER 12 소프트웨어 설계의 프랙털 기하학 209
12.1 성장 210
12.2 혁신 217
12.3 프랙털 기하학 222
12.4 프랙털 모듈성 223
12.5 요점 224
12.6 복습 문제 225
CHAPTER 13 균형 잡힌 결합의 실제 227
13.1 마이크로서비스 227
13.2 아키텍처 패턴 232
13.3 비즈니스 객체 238
13.4 메서드 243
13.5 요점 248
13.6 복습 문제 249
CHAPTER 14 결론 251
맺음말 255
APPENDIX A 결합의 발라드 257
APPENDIX B 결합 관련 용어 261
APPENDIX C 복습 문제 해답 267
참고 문헌 271
찾아보기 276
[본 문]
‘결합(coupling)’이라는 용어는 종종 형편없는 설계를 지칭하는 약어로 사용된다. 시스템 구조가 우리가 하려는 변경에 적극적으로 저항하거나 얽힌 종속성의 미궁에서 빠져나오려고 할 때, 우리는 그것을 결합의 탓으로 돌린다. ‘모든 것을 분리’하는 것이 자연스러운 경향이다. 클래스, 모듈, 서비스 또는 전체 시스템이든 간에 우리는 그것들을 분리하는 경향이 있는데, 구성요소를 더 작게 만듦으로써 각 구성요소를 독립적으로 구현하고 발전시킬 수 있는 자유를 얻을 수 있기 때문이다. / 하지만 결합이 꼭 모든 악의 근원일까? / 결합이 전혀 없는 시스템을 상상해 보자. 모든 구성요소가 독립적이고 상호 교환 가능하다. 이것이 좋은 설계일까? 그런 시스템이 비즈니스 목표를 달성할 수 있을까? (3쪽)
‘모듈’이라는 용어는 소프트웨어 엔지니어링에서 광범위하게 사용되지만, 소프트웨어 모듈이 무엇인지 정의하는 것은 생각처럼 간단하지 않다. 이 용어는 소프트웨어 엔지니어링이 발전하는 와중에 원래 의미가 불분명해지면서 다양하게 재해석되고 정확한 정의가 상실되어 의미가 모호해졌다. / 무엇이 소프트웨어 모듈을 만드는가? 라이브러리, 패키지, 객체, 객체 그룹 또는 서비스일까? 또한 모듈적이지 않은 소프트웨어 구성요소는 무엇이며 모듈과 어떻게 다를까? (…) 소프트웨어 모듈이 정확히 무엇인지 이해하기 위해 시간을 거슬러 올라가서 ‘모듈’이라는 용어가 소프트웨어 설계에 처음 도입되었을 때 무슨 의미였는지 살펴보겠다. (60쪽)
값 공생성(connascence of value)은 거의 가장 높은 수준의 공생성이다. 이 수준은 시스템의 여러 요소 간의 강력한 기능적 관계를 설명한다. 원자적 트랜잭션과 같이 값이 동시에 변경되어야 하는데 그렇지 않을 경우 시스템을 잘못된 상태에 놓이게 하는 값들은 값 공생성을 갖는다. / 값 공생성의 간단한 예는 산술 제약 조건이다. 삼각형 변의 길이를 나타내는 3개의 변수(EdgeA, EdgeB, EdgeC)가 포함된 코드 6.12의 구조를 살펴보자. (…) 비즈니스 규칙과 불변식에 의해 주도되는 제약은 좀 더 일반적이다. 다음과 같은 비즈니스 규칙을 구현해야 하는 소매 시스템을 생각해 보자. 고객이 검증되면 영업 에이전트가 우선 배송으로 등급을 올려줄 수 있다. 고객이 코드 6.13에 표시된 필드가 있는 객체로 표현된다고 가정하겠다. (105~106쪽)
모든 구성요소가 경계를 넘어 과도하고 불필요한 지식을 공유하는 강력하게 결합된 시스템을 상상해 보자. 심지어 침입 결합도 있다. 설계에는 결함이 너무 많아서 어떤 구성요소에 대한 변경이든 필연적으로 파급 효과를 일으켜 모든 가능한 거리에 걸쳐 연쇄적 변경으로 이어질 것이다. (…) 이 장에서는 결합 효과에 대한 논의를 다른 차원, 즉 시간 차원으로 옮긴다. 구체적으로 모듈의 변동성, 즉 모듈이 얼마나 자주 변경될 것으로 예상되는지를 살펴본다. 이를 위해 시스템이 시간이 지남에 따라 어떻게 진화하는지 배우고, 일반적인 진화 요인을 식별하고, 모듈의 예상 변동성(volatility) 수준을 평가하기 위한 전략을 알아본다. (159쪽)
팀은 클래스의 데이터를 기본 데이터베이스에 매핑하기 위해 ORM 라이브러리를 사용하기로 결정했다. 객체 간의 양방향 관계 설계와 결합된 라이브러리는 단일 데이터베이스 트랜잭션에서 아무리 많은 객체에 대한 변경사항이라도 커밋할 수 있도록 했다. / 이 솔루션은 처음에는 편리해 보였지만 팀은 이로 인해 여러 가지 문제에 직면했다. 첫째, 엔지니어는 객체를 탐색하는 옵션을 ‘과도하게 사용’했다. 예를 들어 지원 사례를 열고, 이를 연 고객을 가져온 다음, 같은 고객에게 속한 다른 모든 사례를 로드했다. 이로 인해 데이터를 읽을 때 성능 문제가 발생했을 뿐만 아니라 동일한 데이터베이스 트랜잭션에서 많은 수의 객체에 대한 변경사항을 커밋할 때도 성능 문제가 발생했다. (240쪽)
모듈성은 함께 변경해야 하는 구성요소를 공동 배치하고, 공동 진화할 필요가 없는 구성요소를 분산해야 한다. 복잡성은 정반대다. 그림 14.1에서 볼 수 있듯이 모듈성과 복잡성은 모두 공유 지식과 거리의 조합을 반영한다. 결합력을 정렬하면 시스템의 복잡성이 증가하는 반면, 모듈성은 공유 지식과 거리가 반비례해야 한다. (…) 다양한 모델로 시스템 구성요소의 변동성을 평가할 수 있다. 이 책에서 사용한 모델은 도메인 주도 설계의 하위 도메인이다. 가장 변동성이 큰 하위 도메인 유형은 핵심인 반면, 지원 및 일반 하위 도메인은 그렇게 자주 변경되지 않을 것으로 간주된다. (252쪽)
디커플링 만능론을 깨고 ‘의도된 연결’을 설계하라
좋은 소프트웨어 설계는 왜 이렇게 어려울까? 모듈 이름 하나 바꿨을 뿐인데 시스템 절반이 흔들리고, 기능 하나 추가하는 일이 폭탄 해체처럼 느껴진다면 문제는 구현 기술이 아니라 설계의 결합(커플링) 방식에 있을지 모른다. 좋은 소프트웨어 시스템을 구축하려면 결합을 제대로 다뤄야 한다. 그 중요성에도 불구하고, 결합은 지금까지 충분한 주목을 받지 못하고 오히려 없애야 할 대상으로 지목되곤 했다.
결합은 함수 작성부터 객체 모델 설계, 그리고 분산 시스템을 아키텍처 수준에서 구성하는 데에까지 거의 모든 설계 결정에 영향을 미친다. 결합을 0으로 만드는 일이 불가능하다는 것을 우리는 이미 알고 있다. 이 책은 50년 이상 연구된 소프트웨어 공학의 통찰을 바탕으로, 구조적 설계에서 출발해 공생성 모델로 이어지는 고전적인 결합 이론과 현대 분산 시스템의 복잡한 현실을 잇는 실용적 프레임워크를 제시한다. 저자는 결합을 무조건 줄여야 할 대상이 아니라, 모듈성, 복잡성, 변경 비용 같은 판단 기준에 의한 ‘설계 결정’으로 재정의한다.
통합 강도, 거리, 변동성 등 결합의 세 가지 핵심 차원을 관통하는 ‘균형 잡힌 결합’ 설계 프레임워크를 통해, 결합이 다양한 차원에서 어떤 영향을 미치는지 식별하고 평가하는 방법을 제시한다. 왜 어떤 설계는 복잡성을 낳고, 어떤 설계는 모듈성을 높이는지, 구체적인 사례와 함께 그 이유를 탐구한다. 모듈화되고, 진화 가능하며, 안정적인 소프트웨어 시스템을 설계하고 싶은 아키텍트와 개발자라면 꼭 읽어볼 가치가 있는 책이다.
주요 내용
●결합의 개념을 정의하고, 그것이 시스템 설계와 아키텍처에서 어떤 역할을 하는지 설명한다.
●결합은 시스템의 복잡성을 키우는 원인인 동시에 모듈성을 만드는 기반이 될 수 있음을 보여준다.
●결합을 모듈식 소프트웨어 설계를 위한 실질적인 도구로 바꾸는 통합적 프레임워크를 소개한다.
●소프트웨어 시스템이 지속적으로 성장하는 과정에 맞춰 설계 결정을 어떻게 진화시켜야 하는지 안내한다.