Clean Architecture (로버트 C. 마틴) - 2

이 글은 로버트 C. 마틴의 'Clean Architecture'를 읽고 정리한 문서이며, 총 3부작으로 구성되어 있습니다.

 

Clean Architecture (로버트 C. 마틴) - 1

Clean Architecture (로버트 C. 마틴) - 3

 

[ CHAPTER 3 ] 설계 원칙 

 

[ 7장 – SRP: 단일 책임 원칙 ]

#1. 하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다.

 

#2. SRP는 서로 다른 액터가 의존하는 코드를 서로 분리하라고 말한다.

 

[ 8장 – OCP: 개방 폐쇄 원칙 ]

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

 

#2. OCP는 시스템의 아키텍처를 떠받치는 원동력 중 하나다. OCP의 목표는 시스템을 확장하기 쉬운 동시에 변경으로 인해 시스템이 너무 많은 영향을 받지 않도록 하는 데 있다. 이러한 목표를 달성하려면 시스템을 컴포넌트 단위로 분리하고, 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있는 형태의 의존성 계층구조가 만들어지도록 해야 한다.

 

[ 9장 – LSP: 리스코프 치환 원칙 ]

#1. 여기에서 필요한 것은 다음과 같은 치환 원칙이다. S 타입의 객체 o1 각각에 대응하는 T 타입 객체 o2가 있고, T 타입을 이용해서 정의한 모든 프로그램 P에서 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위 타입이다.

 

[ 10장 – ISP: 인터페이스 분리 원칙 ]

#1. 정적 타입 언어는 사용자가 import, use 또는 include와 같은 타입 선언문을 사용하도록 강제한다. 이처럼 소스 코드에 ‘포함된’ 선언문으로 인해 소스 코드 의존성이 발생하고, 이로 인해 재컴파일 또는 재배포가 강제되는 상황이 무조건 초래된다.

 

#2. 불필요한 짐을 실은 무언가에 의존하면 예상치도 못한 문제에 빠진다.

 

[ 11장 – DIP: 의존성 역전 원칙 ]

#1. 의존성 역전 원칙에서 말하는 ‘유연성이 극대화된 시스템’이란 소스 코드 의존성이 추상(abstract)에 의존하며 구체(concrete)에는 의존하지 않는 시스템이다.

 

#2. 우리가 의존하지 않도록 피하고자 하는 것은 바로 변동성이 큰 구체적인 요소다. 그리고 이 구체적인 요소는 우리가 열심히 개발하는 중이라 자주 변경될 수밖에 없는 모듈들이다.

 

#3. 실제로 뛰어난 소프트웨어 설계자와 아키텍트라면 인터페이스의 변동성을 낮추기 위해 애쓴다. 인터페이스를 변경하지 않고도 구현체에 기능을 추가할 수 있는 방법을 찾기 위해 노력한다. 이는 소프트웨어 설계의 기본이다.

 

#4. 제어 흐름은 소스 코드 의존성과는 정반대 방향으로 곡선을 가로지른다는 사실에 주목하자. 다시 말해 소스 코드 의존성은 제어 흐름과는 반대 방향으로 역전된다. 이러한 이유로 이 원칙을 의존성 역전(Dependency Inversion)이라고 부른다.

 

 

 

 

[ CHAPTER 4 ] 컴포넌트 원칙 

 

[ 13장 – 컴포넌트 응집도 ]

#1. REP(재사용/릴리즈 등가 원칙) : 재사용 단위는 릴리스 단위와 같다.

 

#2. CCP(공통 폐쇄 원칙) : 동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어라. 서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리하라.

 

#3. CRP(공통 재사용 원칙) : 컴포넌트 사용자들에게 필요하지 않는 것에 의존하게 강요하지 말라.

 

#4. 아마도 응집도에 관한 세 원칙이 서로 상충된다는 사실을 눈치챘을 거라고 본다. REP와 CCP는 포함(include) 원칙이다. 즉, 두 원칙은 컴포넌트를 더욱 크게 만든다. CRP는 배제(exclusive) 원칙이며, 컴포넌트를 더욱 작게 만든다. 뛰어난 아키텍트라면 이 원칙들이 균형을 이루는 방법을 찾아야 한다.

 

[ 14장 – 컴포넌트 결합 ]

#1. 컴포넌트 구조와 관련된 아키텍처를 침범하는 힘은 기술적이며, 정치적이고, 가변적이다.

 

#2. ADP(의존성 비순환 원칙) : 컴포넌트 의존성 그래프에 순환이 있어서는 안 된다.

 

#3. SDP(안정된 의존성 원칙) : 안정성의 방향으로 (더 안정된 쪽에) 의존하라.

 

#4. SAP(안정된 추상화 원칙) : 컴포넌트는 안정된 정도만큼만 추상화되어야 한다.

 

#5. 고수준 정책을 안정된 컴포넌트에 위치시키면, 그 정책을 포함하는 소스 코드는 수정하기가 어려워진다. 이로 인해 시스템 전체 아키텍처가 유연성을 잃는다.

 

#6. 이 장에서 설명한 ‘의존성 관리 지표’는 설계의 의존성과 추상화 정도가 내가 ‘훌륭한’ 패턴이라고 생각하는 수준에 얼마나 잘 부합하는지를 측정한다.