• 개방-폐쇄 원칙은 다음과 같다

  소프트웨어 개체는 확장에는 열려있어야 하고, 변경에는 닫혀 있어야 한다
  

• 소프트웨어 개체의 행위는 확장할 수 있어야 하지만, 이때 산출물을 변경해서는 안 된다

• 소프트웨어 아키텍처를 공부하는 가장 근본적인 이유가 바로 이 때문

• 만약 요구사항을 살짝 확장하는 데 소프트웨어를 엄청나게 수정하면, 그 아키텍트는 엄청난 실패에 맞닥뜨린 것

사고 실험

• 재무 제표를 웹 페이지로 보여주는 시스템이 있다고 가정

• 웹 페이지에 표시되는 데이터는 스크롤할 수 있으며, 음수는 빨간색으로 출력

• 이해관계자가 기능 수정을 요청할 때 아키텍처가 훌륭하다면 코드의 양이 가능한 한 최소화 될 것

  (이상적인 변경량은 0)

• 단일 원칙 책임을 적용하면 데이터 흐름을 그림 8.1과 같은 형태로 만들 수 있다

• 그림 8.1 SRP 적용하기

• 위와 같이 책임을 분리했다면 두 책임 중 하나에서 변경이 발생하더라도 다른 하나는 변경하지 않도록 소스 코드 의존성도 확실히 조직화해야 한다

• 또한, 새로 조직화한 구조에서는 행위가 확장될 때 변경이 발생하지 않음을 보장해야 한다

• 이를 위해선 처리 과정을 클래스 단위로 분할하고, 이들 클래스를 그림 8.2에서 이중선으로 표시한 컴포넌트 단위로 구분해야 한다

• 그림 8.2 처리 과정을 클래스 단위로 분할하고, 클래스는 컴포넌트 단위로 분리한다

• 그림 8.3

방향성 제어

• 그림 8.2는 컴포넌트 간 의존성이 제대로 된 방향으로 향하고 있음을 확실히 보여주기 위해서이다
• 예를 들어 FinancialDataGateway 인터페이스는 FinancialReportGenerator와 FinancialDataMapper 사이에 위치하는데 이는 의존성을 역전시키기 위해서다. 이게 없다면 Interactor에서 Database로 바로 향하게 된다

정보 은닉

• FinancialReportRequester 인터페이스는 방향성 제어와는 다른 목적을 가진다