[Clean Architecture] 2️⃣ | Dependency Rule

Dependency Rule ?

• Clean Architecture의 핵심!

모든 소스코드의 경계는 반드시 outer에서 inner로 향해야 한다.

domain(=usecase& entity)은 infrastructure(=UI& DB& Framework)

• 가장 안쪽에 있는 비즈니스 로직은 바깥쪽 계층 중 무엇이 변경되더라도 바뀌지 않아야한다.
• inner circles 안에 있는 것들은 outer circles에 대해 컴포넌트를 알아서도 안되고, 변경에 따라 영향받지도 않아야 한다.
• outer저수준 ➡️ inner고수준 으로 의존성을 가지게 된다

고수준과 저수준은 추상화의 정도에 따라 분류될 수 있다. 추상화가 많이 되어 있을수록 고수준이라고 할 수 있다.

추상화 ?

함수 이름을 통해서 구체적으로 하는 일을 추상화해서 나타낸다.방법: 인터페이스 안에 함수를 쓰는 것

인터페이스 알고 가기 !

• 객체에 대한 명제!(이 객체가 어떤 메서드들을 제공하고 역할을 하는지에 대한 일종의 설명서로 대부분 설계단계에서 만들게 된다)
• 객체와 객체 사이의 상호 작용을 나타낸다.

예를들어 sendMessage라는 함수는 '메세지를 보내는 로직'정도로 해석되지 어떤 내용을 보내는지는 알수 없다. 이처럼 어떤 행위를 하는지 알지만 내용을 알지 못할 때 추상적이라고 말할 수 있다.

(추상화에는 3가지 유형 존재 - 과정 추상화 / 데이터 추상화 / 제어 추상화)

Dependency Inversion Priciple(의존성 역전 원칙) ?

• 추후 공부할 5가지 SOLID 원칙 중 하나

고수준(Use cases)이 저수준(Presenter)를 호출하는 경우

• 유스케이스 내부에 프레젠터의 인터페이스를 정의하고, 프레젠터에 이 인터페이스를 구현
• 이를 통해 고수준(Use cases)은 저수준(Presenter)의 세부사항을 알 필요 없고 변동사항에도 영향을 받지 않게 된다. ... 점선 화살표가 실제 제어 흐름➖ 실선 화살표가 구현 방법
  

즉, 구체적인 클래스보다 인터페이스나 추상 클래스와 관계를 맺어 데이터를 활용하라는 것.