2.2 계층 구조 아키텍처

계층 구조에서는 서비스가 인프라스트럭처 계층에 의존하게 되는데 이런 경우 다음과 같은 문제가 있다.

1. 테스트의 어려움

   • 인프라스트럭처 관련 설정을 다 해줘야 테스트가 가능함

   → 이건 Mock 쓰면 테스트 가능한거 아닌가..?

2. 기능 확장의 어려움

   • 서비스 코드에 인프라스트럭처 직간접적으로 의존성이 생긴다.
   • 예를 들어 특정 인프라스트럭처가 제공하는 메서드의 인자를 넘기기 위해 service 계층에서 해당 인자 관련 데이터를 만들어주는 작업이 필요하다.
   • 이렇게 되면 다른 기술의 인프라스트럭처로 바꿔야할 때 어려움이 생긴다.

   → 인프라스트럭처 기술을 바꾸는 일은 거의 없지않나..? DB, DB 접근기술 등등은 바꾸는걸 거의 못봤는데..

2.3 DIP

[고수준 모듈]

• 의미있는 단일 기능을 제공하는 모듈
• 고수준 모듈의 기능을 구현하려면 여러 하위 기능이 필요하다.
• e.g) Serivce

[저수준 모듈]

• 고수준 모듈이 이용하는 하위 기능들을 구현하는 모듈
• e.g) infra

고수준 모듈이 저수준 모듈에 의존하면 구현 변경과 테스트가 어렵다는 문제가 발생한다.

코드를 보니 결론은 여러 service에서 infra 클래스를 재사용하기 위해 범용적으로 만들지 말고, infra 클래스를 중복해서 만들더라도 service에 infra를 맞춰야하는 것 같다. → DIP를 이용해서 interface를 만드는 것도 결국 핵심은 이거인듯함.