[개발생각] 동일한 역할의 API 인터페이스를 도메인에서 분리해야할때

다른 방식으로 동작하는 동일한 역할을 하는 API는 깔끔하게 도메인 레이어에서 제거하는게 더 깔끔해진다.

 

도메인 주도 설계 개발을 하게 되면, 아래와 같은 상황이 올때가 있다.

 

예를 들면,

ci를 넘기면, 그 ci의 주민등록상의 주소를 리턴해주는 API를 연동한다고 해보자.

그런데, 해당 API는 불안해서, 또는 다른 이유로 같은 기능을 제공하는 몇개의 다른 API를 보조로 사용하려고 한다.

(A api 죽으면, B api 사용,)

그런데 각각의 A, B API는 응답을 주는 방식이 틀리고, 요청파라미터도 다르다.

하나는 요청하면 바로 응답값을 주는 동기방식이고, 하나는 요청하면, 콜백URL을 통해 나중에 전달해주는 콜백 비동기 방식이다.

 

이런경우, 도메인 서비스에서 비즈니스 로직을 구현할때,

해당 api호출을 제공하는 도메인 Client 인터페이스를 만들고, 구현체는 인프라스트럭쳐에 구현체를 구현하고,

해당 도메인 Client 인터페이스를 도메인 서비스안에서 로직에 포함하여, 구현을 해야할까?

 

A,B api 요청/요청 파라미터는 어차피 동일한 역할을 하기에,

정규화하는 방법으로 요청/응답 파라미터는 도메인 Client 인터페이스에서 표준화하여 정하고,

나머지 api별 개별 파라미터는 map을 통해 추가로 전달받도록하여 어찌저찌 맞춘다고 해도...

(물론, 깔끔한 방법은 아니지만)

(코틀린같은 경우는 typealias를 이용해서, 적어도 개발자에게는 map으로 코드상에 표현하지 않고 의미를 부여할수있는 이름으로는 정의할수있으니...)

typealias AdditionalApiParam = Map<String, String>()

 

 

응답방식이 동기방식, 콜백방식은 사실 도메인 서비스에서 도메인 Client 인터페이스만 가지고 일반화하여 로직을 구현하기는 어렵다.

등기방식을 억지로 콜백방식으로 변형하여, 사용하는 방법이 있긴하지만, 

(동기api에서 받은 응답값을, redis등의 캐시에 담아두고, 쓰는곳에서는 key를 통해 응답값을 꺼내쓰게 맞추면, 얼추 맞출수는 있다)

- 동기를 비동기로 굳이 만들어서 사용하는 느낌이랄까?

- 상당히 찜찜하다. 이렇게 까지 해야하는가? 라는 생각...

 

api가 언제 또 다른 방법으로 바뀔수있다고 한다면, 더더욱 맞추기가 어렵다.

 

이런경우는 깔끔하게, 도메인 서비스 영역에서,

과감하게, 도메인 Client 인터페이스의 사용한 로직을 제거하고, application레이어에서 도메인 Client 인터페이스를 수행하고, 응답받은 값을 도메인 서비스로 파라미터로 전달받는 방식으로 수정을 하는게 좋은것 같다.

 

api가 어떤 방식이던, application에서 호출해서 응답값을 도메인 서비스로 파라미터로 전달하게 구조를 만들면,

그 순간부터는 도메인 서비스는 도메인 Client 인터페이스의 방식/방법에 연결고리에서 벗어날수있게 되기때문이다.

 

분명, 개발자라면,

동일한 api의 인터페이스를 정하고, 해당 인터페이스를 도메인 레이어로 가지고와서, 공통된 비즈니스로직에 녹이려는 욕심이 분명 있다.

잘만들면, 엄청 깔끔하게 되고, 재사용성의 영역이 커지기 때문이다.

 

하지만, 위와같은 경우는 억지로 도메인 영역으로 도메인 Client 인터페이스를 녹이려고 하면,

오히려 도메인 영역이 구현체의 역할을 하게되는 실수를 범하게 될 확률이 클것같다.

 

교훈?

도메인 레이어에서의 비즈니스 구현에서, 맞지않는 인터페이스를 꾸겨넣으려는, 욕심은 버리자!!

과감히 버리자! 

어플리케이션 레이어가 그 역할을 해준다는것을 기억하자!!   

:)