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

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

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

모든 구성요소가 경계를 넘어 과도하고 불필요한 지식을 공유하는 강력하게 결합된 시스템을 상상해 보자. 심지어 침입 결합도 있다. 설계에는 결함이 너무 많아서 어떤 구성요소에 대한 변경이든 필연적으로 파급 효과를 일으켜 모든 가능한 거리에 걸쳐 연쇄적 변경으로 이어질 것이다. (…) 이 장에서는 결합 효과에 대한 논의를 다른 차원, 즉 시간 차원으로 옮긴다. 구체적으로 모듈의 변동성, 즉 모듈이 얼마나 자주 변경될 것으로 예상되는지를 살펴본다. 이를 위해 시스템이 시간이 지남에 따라 어떻게 진화하는지 배우고, 일반적인 진화 요인을 식별하고, 모듈의 예상 변동성(volatility) 수준을 평가하기 위한 전략을 알아본다.
---p.159

팀은 클래스의 데이터를 기본 데이터베이스에 매핑하기 위해 ORM 라이브러리를 사용하기로 결정했다. 객체 간의 양방향 관계 설계와 결합된 라이브러리는 단일 데이터베이스 트랜잭션에서 아무리 많은 객체에 대한 변경사항이라도 커밋할 수 있도록 했다. / 이 솔루션은 처음에는 편리해 보였지만 팀은 이로 인해 여러 가지 문제에 직면했다. 첫째, 엔지니어는 객체를 탐색하는 옵션을 ‘과도하게 사용’했다. 예를 들어 지원 사례를 열고, 이를 연 고객을 가져온 다음, 같은 고객에게 속한 다른 모든 사례를 로드했다. 이로 인해 데이터를 읽을 때 성능 문제가 발생했을 뿐만 아니라 동일한 데이터베이스 트랜잭션에서 많은 수의 객체에 대한 변경사항을 커밋할 때도 성능 문제가 발생했다.
---p.240

모듈성은 함께 변경해야 하는 구성요소를 공동 배치하고, 공동 진화할 필요가 없는 구성요소를 분산해야 한다. 복잡성은 정반대다. 그림 14.1에서 볼 수 있듯이 모듈성과 복잡성은 모두 공유 지식과 거리의 조합을 반영한다. 결합력을 정렬하면 시스템의 복잡성이 증가하는 반면, 모듈성은 공유 지식과 거리가 반비례해야 한다. (…) 다양한 모델로 시스템 구성요소의 변동성을 평가할 수 있다. 이 책에서 사용한 모델은 도메인 주도 설계의 하위 도메인이다. 가장 변동성이 큰 하위 도메인 유형은 핵심인 반면, 지원 및 일반 하위 도메인은 그렇게 자주 변경되지 않을 것으로 간주된다.