공통 기능은 도메인을 몰랐으면 좋겠다

1) 서론

아마도 모든 애플리케이션에는 common, core 등으로 불리는 공통 기능들이 있을 것 같은데요.

 

이번에는 이러한 공통 기능을 제공하며, 여러 도메인 사용자의 요청이 섞이면서 어려움을 겪었던 것을 공유드립니다.

일단 귀찮으니 공통

---

 

2) 공통 기능을 제공해봐요

(모든 내용은 임의로 만든 것입니다)

• 모놀리식 A, B 도메인 서버 --> User 도메인 서버 요청

• User 서버 요청하는 Feign client

 

User 서버를 요청하는 Feign 클라이언트를 제공하게 되었는데요. 아무런 도메인이나 비즈니스 로직이 포함되어 있지 않습니다. 즉 어떠한 도메인에서 유저 정보가 필요하면 사용하고, 각 도메인에 맞게 유연하게 다룰 수 있습니다.

 

하지만 아래와 같이 수정 요청을 받습니다.

• A, B 도메인 공통으로 사용하기를 원함
• validation, error handling 등 모두 공통으로 제공 원함

---

3) 모든 것을 공통으로 묶어봅시다

만약 각 도메인에서 일괄적으로 FeignException handling을 요구한다면 어떻게 될까요?

 

일괄적으로 FeignException 시 RuntimeException을 던지도록 만들었습니다. A, B 도메인의 요청에 맞게 잘 구현한 것 같은데요. 하지만 현실 비즈니스는 계속해서 변화하고 복잡해집니다. 오늘의 요구사항을 대응하면서도, 내일의 변경을 대비해야 합니다.

 

만약 이런 경우에는 어떻게 될까요?

• A 도메인에서는 TimeoutException 일 때 재처리 필요
• B 도메인에서는 500 에러인 경우 무시하고 로그만 기록

 

최초의 기능은 User 서버를 요청하여, 유저 정보를 가지고 오는 공통기능이었습니다. 즉 클라이언트를 사용하는 도메인과 철저히 분리했었는데요. 어떠한 도메인의 요구사항이 공통 로직에 들어가 있지 않았습니다. 그래서 사용하는 곳에서 이를 다루면 되기 때문에 유연했습니다.

 

하지만 위의 요구사항으로 인해서 공통 기능이 모든 도메인을 알게 되었습니다. 공통 로직은 A, B 도메인에 대해서 알아야 하고, 각 도메인에 맞게 적절한 처리를 해줘야 합니다. 아마도 If문으로 분기가 생기고, 정작 핵심 비즈니스 로직은 눈에 보이지 않게 될 것입니다.

fun function() {
    if (A domain일 때) ~
    if (B domain일 때) ~ 
    // 기타 등등
}

 

만약 해당 로직이 특정 thread pool을 사용하는 것이라면 어떻게 될까요? A, B 도메인 모두 동일한 pool을 사용하게 될 것입니다. 즉 하나의 도메인에서 다수의 요청이 발생하여 thread를 사용하게 되면, 다른 도메인에서도 지연이 발생할 것 입니다. 장애전파라는 관점에서 좋지 않습니다.

 

심지어 해당 로직을 수정한 뒤 테스트는 더욱 어려울 것입니다. 해당 로직에 포함되어 있는 모든 도메인에서 테스트가 이루어져야 합니다. 즉 단위 테스트는 불가능하고, 각 도메인에서 통합 테스트가 이루어져야 합니다. 혹은 모든 것을 mock처리하는 의미가 떨어지는 단위테스트만 가능할 것입니다.

 

즉 도메인과 공통 로직이 강결합이 되어, 유지보수에 매우 불리해집니다.

---

4) 결론

사실 공통 모듈, 클래스를 철저히 관리하지 않는다면 쉽게 비즈니스 로직에 의해 오염되는데요. 애매할 때는 일단 '공통'이라고 칭하며 넣게 되기도 합니다. 흔히 '공통의 저주'라고 불리기도 합니다.

 

개인적으로 생각하는 공통은 어떠한 도메인도 알 필요도 없고, 알지 못해야 한다고 생각합니다.  각 도메인에서 다르게 활용해야 한다면 전략 패턴과 같이 디자인 패턴으로 풀어내는 것이 더 좋다고 생각합니다.

 

현실의 비즈니스는 계속해서 복잡해져 가고 커져갈 것입니다. 그래서 처음부터 결합도를 최대한 낮추는 방향으로 설계를 하고, 팀 전체가 이것을 지키도록 하는 것이 중요하다고 생각합니다.