소프트웨어 설계의 결합 균형

옮긴이 머리말 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)'이라는 용어는 종종 형편없는 설계를 지칭하는 약어로 사용된다. 시스템 구조가 우리가 하려는 변경에 적극적으로 저항하거나 얽힌 종속성의 미궁에서 빠져나오려고 할 때, 우리는 그것을 결합의 탓으로 돌린다. '모든 것을 분리'하는 것이 자연스러운 경향이다. 클래스, 모듈, 서비스 또는 전체 시스템이든 간에 우리는 그것들을 분리하는 경향이 있는데, 구성요소를 더 작게 만듦으로써 각 구성요소를 독립적으로 구현하고 발전시킬 수 있는 자유를 얻을 수 있기 때문이다. / 하지만 결합이 꼭 모든 악의 근원일까? / 결합이 전혀 없는 시스템을 상상해 보자. 모든 구성요소가 독립적이고 상호 교환 가능하다. 이것이 좋은 설계일까? 그런 시스템이 비즈니스 목표를 달성할 수 있을까?

'모듈'이라는 용어는 소프트웨어 엔지니어링에서 광범위하게 사용되지만, 소프트웨어 모듈이 무엇인지 정의하는 것은 생각처럼 간단하지 않다. 이 용어는 소프트웨어 엔지니어링이 발전하는 와중에 원래 의미가 불분명해지면서 다양하게 재해석되고 정확한 정의가 상실되어 의미가 모호해졌다. / 무엇이 소프트웨어 모듈을 만드는가? 라이브러리, 패키지, 객체, 객체 그룹 또는 서비스일까? 또한 모듈적이지 않은 소프트웨어 구성요소는 무엇이며 모듈과 어떻게 다를까? (…) 소프트웨어 모듈이 정확히 무엇인지 이해하기 위해 시간을 거슬러 올라가서 '모듈'이라는 용어가 소프트웨어 설계에 처음 도입되었을 때 무슨 의미였는지 살펴보겠다.

값 공생성(connascence of value)은 거의 가장 높은 수준의 공생성이다. 이 수준은 시스템의 여러 요소 간의 강력한 기능적 관계를 설명한다. 원자적 트랜잭션과 같이 값이 동시에 변경되어야 하는데 그렇지 않을 경우 시스템을 잘못된 상태에 놓이게 하는 값들은 값 공생성을 갖는다. / 값 공생성의 간단한 예는 산술 제약 조건이다. 삼각형 변의 길이를 나타내는 3개의 변수(EdgeA, EdgeB, EdgeC)가 포함된 코드 6.12의 구조를 살펴보자. (…) 비즈니스 규칙과 불변식에 의해 주도되는 제약은 좀 더 일반적이다. 다음과 같은 비즈니스 규칙을 구현해야 하는 소매 시스템을 생각해 보자. 고객이 검증되면 영업 에이전트가 우선 배송으로 등급을 올려줄 수 있다. 고객이 코드 6.13에 표시된 필드가 있는 객체로 표현된다고 가정하겠다.