# CH03 코드 구성하기

## 아키텍처적으로 표현력 있는 패키지 구조

여기선 책에서 예시를 드는 패키지 구조가 있는데, 내가 실제로 작업한 패키지 구조를 스크린 샷으로 가져왔다.

<figure><img src="https://1889038796-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ0ynUCwOcYxaUYkg5rP6%2Fuploads%2FOA7qRRcZXfoZDImvIeCz%2Fimage.png?alt=media&#x26;token=70f851fa-7f18-43dd-b946-fd7d34673fae" alt=""><figcaption></figcaption></figure>

<figure><img src="https://1889038796-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ0ynUCwOcYxaUYkg5rP6%2Fuploads%2FoqR2aNhEjIslIcZIwzzV%2Fimage.png?alt=media&#x26;token=ba8702ee-3401-44e0-b523-4a7e8ac1f999" alt=""><figcaption></figcaption></figure>

책에 따르면 '아키텍처-코드 갭' 이라는 용어가 있는데 이 용어의 존재 자체가 소프트웨어 개발 프로젝트에서 아키텍처가 코드에 직접적으로 매핑될 수 없는 추상적 개념이라는 증거라고 하는데, 이러한 표현력 있는 패키지 구조는 '아키텍처-코드 갭'을 효과적으로 다룰 수 있는 수단라고 한다.

즉, 나의 말로 요약하자면 이러한 패키지 구조는 설계라는 추상적 개념을 우리가 잘 느낄 수 있도록 구체적인 레벨로 나타내고, 구현하기에 좋다는 것이다.

또한 책에 따르면 '이처럼 표현력 있는 패키지 구조는 아키텍처에 대한 적극적인 사고를 촉진한다'고 하는데 나도 공감이 갔다. 왜냐하면 추상적인(달리 말해 퉁쳐서 묶어둔) 계층일 수록 새로운 것을 추가하거나 변경 해야할 때 '이거 어디에 넣지' 왜 같은 고민을 할 필요가 없어지고, 위와 같이 세분화 되어 있을 수록 설계론적인 사고를 더 많이 하게 될 수 밖에 없기 때문이다.

## 의존성 주입의 역할

<figure><img src="https://1889038796-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQ0ynUCwOcYxaUYkg5rP6%2Fuploads%2FWJQJdCDxFKuy9r7i5erY%2Fimage.png?alt=media&#x26;token=14265d19-8595-44f7-8f9a-fe69cf838b7b" alt=""><figcaption></figcaption></figure>

도식과 패키지 구조를 다시 보자.

웹 어댑터의 경우 포트만 알 뿐(여기서는 유스케이스를 의미) 유스케이스가 무엇이 주입될 지 알지 못하고 알 필요도 없다.

한편 유스케이스가 의존할 아웃풋 포트의 경우 유스케이스는 이것의 구현체가 어떤 것일지 전혀 알 필요가 없다.(관계형 디비를 쓰든 뭘 쓰든 어떻게 되어있든 기술에 대해서 전혀 알 필요도, 알아서도 안된다)
