배경

사내에 MSA를 도입 해보자는 이야기가 있어서,

이왕이면 제대로 해보고 싶어 요즘 열심히 스터디 중이다.

내가 필요하고 판단한 선수지식은 다음과 같다.

port-adapter pattern에 관해 작성해본다.

Clean Architecture

port adapter pattern은 아키텍처적인 문제를 해결하기 위해 등장한 아키텍처 패턴 중 하나다.
아키텍처는 기본적으로 변경이 어렵다 즉 개선이 어렵다.
좋은 아키텍처는 쉬운 확장, 테스트 하기 쉬운 코드, 높은 품질, 빠른 설계 속도를 목표로 한다.
좋은 아키텍처란 결정을 뒤로 미루는 것이라고 한다. (책 클린 아키텍처 도입부)
- 소프트웨어가 완성 된 후에 더 좋은 아키텍처 결정이 생각남에도 변경이 어려워 적용하지 못한다.
- 따라서 아키텍처 결정을 뒤로 미룰 수 있는 구조가 좋은 구조라 설명한다.
port adapter pattern은 아키텍처적 결정을 뒤로 미루도록 하는 아키텍처 디자인 패턴이다.

아래로 바꿔서 보면 좀더 익숙할 것 같다.

장점
- 개념적으로 모두가 익숙한 아키텍처로 빠른 속도로 개발 가능하다.
단점
- 규모가 커질수록 layer간 의존성이 복잡해지고 유지보수가 어려워진다.
- 플랫폼에 종속적이다.
- 중요한 것은 useCase인데, 개발시 REST API, DB에 집착하게 된다. (DB, API에 의존한 개발)

MSA를 생각해보면 요청(input)의 주체가 다양하다.
- 사용자
- 메시징큐
- 서버A
- 서버B . . .
MSA는 응답(output) 또한 다양하다.
- 클라이언트
- 서버A
- 데이터배이스
- 메시징큐 . . .
즉, 입력/출력이 모놀리틱 아키텍처에 비해 다양하고, 변경의 여지가 높다.
장점
- 입/출력이 interface의 구현을 통해서만 통신 가능하도록 만들면 아키텍처 결정을 뒤로 미룰 수 있다. (유연한 확장을 가능하게 한다.)
- use case, 비즈니스에 집중할 수 있다.
- 변경이 쉬운 구조가 된다.
- 테스트가 쉬워진다. (레이어드 아키텍처에서는 사실상 Data Access Layer는 Mock 하지 않으면 테스트가 불가능한데, port adapter 패턴을 사용하면 Mock을 사용하지 않고 테스트 가능하다.)
단점
- 구현 코드양이 늘어남 (생산성 저하)
- 예를들어 adapter 격리를 위해 DTO 클래스가 추가로 필요하다.
- useCase(service)에 domain 객체를 사용하여 클래스 생성을 줄여보려 했했다 (머리속에서 딱 정한 rule이 아직 없다보니 개발하면서 잡생각이 너무 많아졌다.)
  - Controller에서 사용하는 RequestDTO
  - Service에서 사용하는 Domain
  - Repository에서 사용하는 Entity
  - 응답용도로 사용하는 ResponseDTO

port-adapter 패턴으로 인터페이스(Port)로 domain을 격리하고 요청/응답을 인터페이스 구현(adapter)로 주입하도록 만드는 아키텍처를 핵사고날 아키텍처라고 한다.