MSA 설계 (DDD 적용 예상 구성)

하게 된 이유

https://chainbell.tistory.com/entry/MSA-%EC%B5%9C%EC%86%8C-%EC%84%A4%EA%B3%84-%EC%9A%B4%EC%98%81-%EC%A0%81%EC%9A%A9?category=863960 

MSA 최소 설계 (운영 적용)

이전 MSA 구성을 최소한으로 적용하여 실제 운영 적용했던 경험을 바탕으로 더 개선할 수 없을까 고민하고 있었다.

이 구성은 간단하고 이해하기 쉬워 만족하긴 했지만 어디까지나 각 서버간 상호 작용에 중점을 둔 구성이었다.

프로젝트 내부적 정리는 되지 않은 상태였기 때문에 이번엔 내부적은 개선을 고려해보기로 했다. 

 

적용한 개념 

내부 구조의 정리를 위해 전에 알아봤던 개념들을 오랜만에 꺼내왔다. 

도메인 기반 설계(Domain Driven Design)의 구성 단위이자, MSA 개발의 최소 단위인 Aggregate이다. 

https://chainbell.tistory.com/entry/1-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%ED%8C%A8%ED%84%B4MSA%EC%B5%9C%EC%86%8C-%EB%8B%A8%EC%9C%84-%EC%95%A0%EA%B7%B8%EB%A6%AC%EA%B1%B0%ED%8A%B8aggregate?category=863960 

1. 마이크로서비스 패턴(MSA)최소 단위 : 애그리거트(aggregate)

 

그림으로 보는 구성

기본적인 틀은 MSA Batch Server이다. 하지만 API 서버에도 동일하게 적용할 수 있다.

위 그림에서는 이해를 돕기 위해 Aggregate에서 전달, 반환용 객체는 Aggregate의 범위에서 외부로 걸쳐있는 것처럼 묘사하였다. 

순번대로 설명을 하면 

1) 스케쥴 예약이 된 Batch 서버에서 요청을 담은 Queue로부터 요청을 Pop하여 추출한다.

2) Pop한 요청에 해당하는 Service Method를 호출한다. 

3) Service Method는 Domain Aggregate에 Primary Key를 전달한다.

4) 전달된 Primary Key를 가지고 Aggregate 내에 구현되어있는 실질적인 Service Logic을 실행한다. 

5) 실행된 Service Logic의 결과를 정해진 반환 객체 형태로 변환한다.

6) 반환 객체 형태로 변환된 결과값을 반환한다. 

7) 3)의 과정을 다른 Aggregate에서 진행한다.

8) 4)의 과정을 다른 Aggregate에서 진행한다.

9) 5)의 과정을 다른 Aggregate에서 진행한다.

10) 6)의 과정을 다른 Aggregate에서 진행한다.

11) 3~6, 7~10의 과정으로 반환받은 결과를 정리하여 실행 성공 여부를 반환한다. (API 서버였다면 정리된 결과를 클라이언트에게 반환하면 된다.)

 

이전의 최소 설계와 다른 점은?

이번에 중점을 둔 구간은 3~6번의 과정을 다루는 Aggregate의 구간이다. 최소 적용했던 이전 설계는 Service Class에서 모든 Service Logic을 담고 있기 때문에, Business Logic 별 Service Logic의 정리가 되어 있지 않았다. 그로 인한 Service Logic의 재활용도가 낮았고, Service Class 간의 호출에도 유동적으로 대처할 수 없었다. 

하지만 위 구조로 재설계하면 실질적인 Service Logic은 Domain Aggregate내에 위치하게 되며, Service Class는 Domain으로부터 빌려오기만 하면 된다. 

 

단점은 없을까?

1) 개발 단계에서 Domain, Service Class간 설계에 신경을 많이 써야 한다.

2) 설계의 실수가 발생한 채로 운영까지 배포하게 되면 되돌리기 위한 추가 공수가 발생하게 된다.

3) Domain과 Service Class 사이의 명확한 경계를 제안하는 명세가 필요하게된다. 

 

서버 프로젝트의 구성은?

Aggregate를 적용하기 전에는 Service Package들이 각각 Service Logic과 그에 해당하는 sql들을 보유했다.

하지만 그 역할을 각 Domain이 맡게 되면서 Service Class는 필요한 기능을 명세하는 수준의 코드가 되고, Domain Aggregate의 영역에 Service Logic이 포함되기 때문에 명세와 로직의 구분을 눈으로 볼 수 있도록 위와 같이 분리 시켰다. 

 

위 구상의 적용은 가능할까?

개인 프로젝트로는 위 구성으로 만들어봤자, 이 구조를 위한 프로젝트를 만들어질 뿐이다. 그래서 현재 실무에서 적용할 수 있을지 생각해봤는데, 마침 딱 좋은 프로젝트가 있다. 

실제 적용을 할 순 없겠지만, 동료 개발자와 의논을 해봐야겠다.