클린 아키텍처 - 3부 : 설계 원칙

좋은 소프트웨어 시스템은 깔끔한 코드로부터 시작한다.

Solid 원칙의 목적은 중간 수준의 소프트웨어 구조가 아래 같도록 만드는데 있다.

• 변경에 유연하다.
• 이해하기 쉽다.
• 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트 기반이 된다.

7장 SRP : 단일 책임 원칙

단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다.

변경의 이유란 바로 이들 사용자와 이혜관계자를 가리킨다.

하나의 모듈은 하나의 오직 하나의 사용자 또는 이해관계자에 대해서만 책임져야 한다.

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

모듈은 단순히 함수와 데이터 구조로 구성된 응집된 집합이다.

 

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

 

병합에는 항상 위험이 뒤따르게 된다.

이 문제를 벗어나는 방법은 서로 다른 액터를 뒷바침하는 코드를 서로 분리하는 것이다.

 

퍼사드 패턴 ( 복잡한 하위 클래스들이 있지만, 간단한 인터페이스를 제공함으로 간략화하게 한다. )

ex : 홈쇼핑 전화 주문

덜 중요한 나머지 메서드들에 대한 퍼사드로 사용할 수 있다.

메서드의 개수는 실제로 훨씬 더 많을 것이다. 클래스는 모두 다수의 private 메서드를 포함

 

단일 책임 원칙은 메서드와 클래스 수준의 원칙

컴포넌트 수준에서는 공통 폐쇄 원칙, 아키텍처 수준에서는 아키텍처 경계의 생성을 책임지는 변경의 축이된다.

 

8장 OCP : 개방-폐쇄 원칙

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

아키텍처 컴포넌트 수준에서 OCP를 고려할 때 훨씬 중요한 의미를 가진다.

 

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

모든 의존성이 소스 코드 의존성을 나타낸다는 사실

모든 컴포넌트 관계는 단방향으로 이루어진다.

화살표는 변경으로부터 보호하려는 컴포넌트를 향하도록 그려진다.

아키택트는 어떻게 왜 언제 발생하는지에 따라서 기능을 분리하고 분리한 기능을 컴포넌트의 계층구조로 조직화 한다. 컴포넌트 계층구조를 이와 같이 조직화 하면 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있다.

 

추이 종속성을 가지게 되면, 소프트 웨어 엔티티는 자신이 직접 사용하지 않는 요소에는 절대로 의존해서는 안된다는 소프트웨어 원칙을 위반하게 된다.

Controller에서 발생한 변경으로부터 Interactor를 보호하는 일의 우선순위가 가장 높지만, 반대로 Interactor에서 발생한 변경으로부터 Controller도 보호되기 바란다. 이를 위해 Interactor 내부를 은닉한다.

 

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

아키텍처 관점에서 LSP를 이해하는 최선의 방법은 이 원칙을 어겼을 때 시스템 아키텍처에서 무슨 일이 일어나는지 관찰하는 것이다.

 

LSP는 아키텍처 수준까지 확장할 수 있고, 반드시 확장해야만 한다. 치환 가능성을 조금이라도 위배하면 시스템 아키텍처가 오염되어 상당량의 별도 메커니즘을 추가해야 할 수 있기 때문이다.

 

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

한 클래스 내에 서로 다른 부분을 의존하고 있을 때 한 곳의 소스코드만 변경해도 전체 배포가 이뤄져야한다.

오퍼레이션을 인터페이스 단위로 분리하여 해결할 수 있다.

 

런타임 추론, 재컴파일과 재배포가 필요없음

동적 타입 언어를 사용하면 정적 타입 언어를 사용할때보다 유연하며 결합도가 낮은 시스템을 만들 수 있는 이유는 바로 이 때문이다.

ISP를 아키텍처가 아니라 언어와 관련된 문제라고 결론내릴 여지가 있다.

 

필요 이상으로 많은 걸 포함하는 모듈에 의존하는 것은 해로운 일

소스코드 의존성의 경우

불필요한 재컴파일과 재배포를 강제하기 때문

아키텍처 수준에서도 마찬가지 상황이 발생한다.

 

11장 DIP : 의존성 역전 원칙

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

인터페이스나 추상 클래스 같은 추상적인 선언만을 참조

구체적인 상대에는 절대 의존해서는 안 된다.

DIP를 논할 때 운영체제나 플랫폼 같이 안정성이 보장된 환경에 대해서는 무시하는 편이다.

 

인터페이스는 구현체보다 변동성이 낮다.

인터페이스를 변경하지 않고도 구현체에 기능을 추가할 수 있는 방법을 찾기 위해 노력한다. 이는 소프트웨어 설계의 기본이다.

 

변동성이 큰 구체 클래스를 참조하지 말라

변동성이 큰 구체 클래스로부터 파생하지 말라.

구체 함수를 오버라이드 하지 말라.

구체적이며 변동성이 크다면 절대로 그 이름을 언급하지 말라.

 

변동성이 큰 구체적인ㅇ 객체는 특별히 주의해서 생성해야 한다.

추상 팩토리 사용

소스코드 의존성은 제어흐름과는 반대 방향으로 역전된다. 이러한 이유로 이 우너칙을 의존성 역전이라고 부른다.

 

DIP 위배를 모두 없앨 수는 없다.

DIP를 위배하는 클래스들은 적은 수의 구체 컴포넌트 내부로 모을 수 있고, 이를 통해 시스템의 나머지 부분과는 분리할 수 있다.

 

더 추상적인 엔티티가 있는 쪽으로만 향한다. 추후 이 규칙은 의존성 규칙이라 부를 것이다.