[목 차]

옮긴이 머리말 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쪽) 

켄트 벡 (익스트림 프로그래밍 창시자, TDD 선구자)
설계는 변화에 대비하는 것이다. 새로운 것들이 나타나는 것이 변화다. (…) 소프트웨어는 시간이 흐를수록 더 쉽게 변경할 수 있게 만들 수 있다. 물론 그러려면 만만치 않은 노력이 필요하다. 하지만 이 책에서 얻게 될 개념과 기술로 무장한다면 잘 헤쳐나갈 수 있을 것이다.

레베카 J. 워프스브록 (소프트웨어 설계 전문가)
이 책에서 블라드는 모듈 결합과 공생성이 갖는 원래의 설계 아이디어를 알려준 후, 결합의 다양한 차원, 즉 통합 강도, 변동성, 거리에 대해 생각할 수 있는 새로운 방법을 알려준다. 그런 다음 결합을 깊이 이해하는 여정으로 우리를 인도하고 시스템의 일부를 설계하거나 리팩터링할 때 결합 옵션을 평가하기 위한 포괄적인 모델을 제시한다. 대부분의 저자는 결합을 설명하는 데 한 단락이나 한 페이지 정도를 할애하는데, 블라드는 책 전체에 걸쳐 설명하고 있다. (…) 결합을 항상 나쁜 것으로 봐야 할까? 물론 그렇지는 않다. 하지만 자만해서도 안 된다. 책의 마지막 부분에서는 균형 잡힌 결합 개념과 시스템에서 결합을 ‘재조정’할 때 설계 의미를 생각하는 프로세스를 소개한다.