클린아키텍처 2주차

스터디 범위 7장 ~ 10장

참여자 총 7명

• @LIAM
• @BRANDON
• @CHRIS
• @LEO
• @PARKER
• @ODIN
• @BUZZ

7장 - SRP: 단일 책임 원칙

• 단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다.
• 소프트웨어 시스템은 사용자와 이해관계자를 만족시키기 위해 변경된다.
  → 하나의 모듈은 하나의, 오직 하나의 사용자 또는 이해관계자에 대해서만 책임져야 한다.
• 사용자, 이해관계자는 해당 변경을 요청하는 한 명 이상의 사람들을 가리킨다. ⇒ 액터actor
  → 하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다.

단일 액터를 책임지는 코드를 함께 묶어주는 힘이 바로 응집성cohesion이다.

💡 응집도는 서로 어떻게 관련되어 있는지를 가리킨다.
정확히 말하자면 응집도는 클래스나 메서드의 책임이 서로 얼마나 강하게 연결되어 있는지를 측정한다.

8장 - OCP: 개방-폐쇄 원칙

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

다시 말해 소프트웨어 개체의 행위는 확장할 수 있어야 하지만, 변경해서는 안된다.

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

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

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

val o1: S
val o2: T

fun P() {
	o2: T // <= o2: S 로 치환 가능?
}

o2를 사용한 모든 프로그램을 o1으로 치환 가능하다
 == S(o1)은 T(o2)의 하위 타입이다 (S extends T)

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

각자의 기능에 맞는 인터페이스만을 만들어 분리하고 독립적으로 동작하게 한다

의존에 의해서 사용하지 않는 기능이 포함되어있을 수 있고, 그 때문에 원치않는 재배포가 이루어 질 수 있다.
마이크로서비스 패턴

11장 - DIP: 의존성 역전 원칙

• 의존성 역전 원칙DIP에서 말하는 유연성이 극대화된 시스템:
  소스 코드 의존성이 추상abstraction에 의존하며 구체concretion에는 의존하지 않는 시스템
  - 소프트웨어 시스템 이라면 구체적인 많은 장치(e.g. String)에 반드시 의존한다.
  - 우리가 의존하지 않도록 피하고자 하는 것은 바로 변동성이 큰volatile 구체 적인 요소다.
  (DIP를 논할 때 운영체제나 플랫폼 같이 안정성이 보장된 환경에 대해서는 무시하는 편이다.)
  
• 추상 인터페이스에 변경이 생기면 이를 구체화한 구현체들도 따라서 수정해야 한다. (추상 인터페이스에는 의존하기 때문에) 반대로 인터페이스 구현체에 변경이 생기더라도 추상 인터페이스는 항상/대다수의 경우 변경될 필요가 없다.
  
• 인터페이스를 변경하지 않고도 구현체에 기능을 추가 할 수 있는 방법을 찾기 위해 노력한다.
  (*OCP와 연관 시켜 생각할 수 있을 것이다*)

  ⇒  안정된 소프트웨어 아키텍처란 변동성이 큰 `구현체에 의존하는 일은 지양`하고, 안정된 추상 인터페이스를 선호하는 아키텍처라는 뜻이다.

• 변동성이 큰 구체적인 객체는 특별히 주의해서 생성해야 한다.
  → 객체를 생성하려면 해당 객체를 구체적으로 정의한 코드에 대해 소스 코드 의존성이 발생하기 때문이다.
  

여기서 곡선은 `아키텍처 경계`(구체적인 것들로 추상적인 것들을 분리)를 뜻한다.  
소스 코드 의존성은 해당 곡선과 교차할 때 모두 한 방향, 즉 `추상적인 쪽으로 향한다`.
소스 코드 의존성은 `제어흐름과는 반대 방향으로 역전`된다.
⇒ `의존성 역전Dependency Inversion`

의존성은 곡선을 경계로, 더 추상적인 엔티티가 있는 쪽으로만 향한다. 
이 규칙은 `의존성 규칙Dependency Rule`이라 부를 것이다.