Ch2 의존성 역전하기

[s-ryuri]

(p13) 1. 단일 책임 원칙의 의미를 컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.라고 썼는데. 여기서 오직 하나뿐이라는 의미?

• 의존 관계가 하나만 있어야 된다는 의미인가?

(p13) 2. "아키텍처에서의 의미는 만일 컴포넌트를 변경할 이유가 한 가지라면 우리가 어떤 다른 이유로 소프트웨어를 변경하더라도 이 컴포넌트에 대해서는 전혀 신경 쓸 필요가 없다는 의미이다. 소프트웨어가 변경되더라도 여전히 우리가 기대한 대로 동작할 것이기 때문이다."

1. 소프트웨어의 변경과 컴포넌트의 변경은 다른가..?
2. 그리고 왜 소프트웨어를 변경해도 컴포넌트에 대해서는 전혀 신경 쓸 필요가 없을까.?
   • E를 보면 의존 하는 게 전혀 없는 데 의존하는 게 없을 수 있나? (영속성 제외) 읽으면 좋은 글 : https://techblog.woowahan.com/2647/

정리

• 보통 단일 책임 원칙 처음 배울 때 하나의 클래스에 하나의 책임이 있어야된다고 배우는데 책에서는 "책임"보다는 "변경할 이유"에 초점을 맞추고 의존관계에도 초점을 맞춰서 얘기함.
• https://eratosthenes.tistory.com/3
• 위의 링크를 보면 User 컴포넌트에 이메일 컴포넌트까지도 있게 됨
• 이렇게 되면 처음에 배우는 하나의 클래스에 두 개의 책임이 있기에 단일 책임 원칙에 위반됨
• 그리고 책을 기준으로 보면 이메일 컴포넌트가 바꾸는 순간 유저 컴포넌트가 바뀌게 되므로 유저 컴포넌트의 변경할 이유가 한 가지가 아니게 됨, 그렇기에 단일 책임 원칙에 위반이 된다.

[s-ryuri]

(p15) "단일 책임 원칙을 고수준에서 적용할 때 상위 계층들이 하위 계층들에 비해 변경할 이유가 더 많다는 것을 알 수 있다."

1. 고수준, 상위 계층, 하위 계층 의미 아마 의존성 관련 같기는 한데

   
   아래의 글을 읽다보면 고수준, 저수준이라는 단어가 자주 등장하는데 대략적으로 다음과 같다고 생각합니다.

2. 고수준 : 상위 수준의 개념, 추상화된 개념

   • 예시: 데이터를 저장한다, 구역 배달료를 구한다

3. 저수준 : 추상화된 개념을 실제 어떻게 구현할지에 대한 세부적인 개념

   • 예시: RDB에 데이터를 저장한다, 폴리곤 구역에 속한 배달건에 대해 배달료를 구한다

     
     ![image](https://user-images.githubusercontent.com/66999675/172317834-13107ae3-c276-4496-b816-14898fdb4666.png)

4. 왜 상위 계층들이 변경할 이유가 더 많을까?

5. 쌍따옴표 안에 있는 문장이 DIP를 적용하지 않았다는 가정하에 쓴 말일까?

정리 1, 2 고수준/저수준 과 상위/하위 계층 개념은 아예 다른 개념

• 출처 : https://koseungbin.gitbook.io/wiki/books/undefined/part-2.-di/solid/dependency-inversion-principle
• 고수준 모듈의 기능을 도메인 기능에서 구현을 한다고 하면 결국 상위수준에서만 기능을 바꾸기에 상위 계층이 하위 계층들에 비해서 변경할 이유가 많아진다.
• 근데 저수준 모듈이라고 하면 데이터를 읽는 것은 결국 하위계층과 관련된 부분이기에 상위 계층을 바꾸는 것이 아닌 하위 계층을 위주로 바꾸게 된다.

[s-ryuri]

(p19) "JPA에서는 ORM이 관리하는 엔티티에 인자가 없는 기본 생성자를 추가하도록 강제하는데 이것이 바로 도메인 모델에는 포함해서는 안 될 프레임워크에 특화된 결합의 예." 무슨 의미일까..

• JPA를 사용하면 도메인에 기본 생성자를 추가해야만 하기에, 결국 JPA를 사용하기에 도메인 모델에 프레임워크와 관련된 걸 추가해야돼서 특화된 결합의 예이다.?

[s-ryuri]

• 화살표의 색깔이 다름 (p20) 헥사고날 아키텍처에서의 어댑터의 의미? 무엇을 하는가?

• 내부 영역은 순수한 비즈니스 로직을 표현하는 영역으로 외부 영역과 연계되는 포트(Port)를 가지고 있고

• 외부 영역은 외부에서 들어오는 요청을 처리하는 인 바운드 어댑터(Inbound Adpater)와

• 비즈니스 로직에 의해 호출되어 외부와 연계되는 아웃 바운드 어댑터(Outbound Adapter)로 구성됩니다.

• 포트는 인 바운드(Inbound)/아웃 바운드(Outbound) 포트로 구분되고

• 인 바운드 포트는 내부 영역 사용을 위해 표출된 API이며, 외부 영역의 인 바운드 어댑터가 호출한다.

• 아웃 바운드 포트는 내부 영역이 외부를 호출하는 방법을 정의합니다.

• 포트는 인터페이스, 어댑터는 구현체?

(p21) "왼쪽 어댑터는 애플리케이션 코어를 호출하기에 애플리케이션을 주도하는 어댑터, 오른쪽은 애플리케이션에 의해 호출되기에 애플리케이션에 의해 주도되는 어댑터이다" -> 호출하는 것과 호츨되는 것의 차이?

정리

1. 포트와 어댑터 원래 뜻 그대로의 느낌
2. 포트를 인터페이스로 구현하고 어댑터는 구현체로 구현