Common 모듈 사용시의 주의점

개요

저희 At_ticket 프로젝트는 기능들 간의 의존성을 줄이기 위하여 멀티 모듈로 구성되어있습니다.
그래서 공통으로 사용하는 코드들도 분리하여 공통 모듈(Common 모듈)이라는 모듈을 따로 만들면 좋겠다는 생각을 하였습니다.

모듈을 분리하기에 앞서,
Common 모듈을 잘못사용했을 때 생길 수 있는 문제점에 대해 생각해보았습니다.

Common의 문제점

위와 이미지와 같이 비슷한 작업을 하는 코드를 일반화하여 범용 처리 기능을 담당하는 모듈로 만든다고 가정해봅시다.

▲ 중복 로직을 모아서 Common 모듈로 분리함

이렇게 만들어진 공통모듈은 처음에는 아무 문제가 없어 보입니다.

기능이 추가되기 시작하면서, Common 모듈에도 각 모듈에 관련된 코드들이 추가되기 시작할 것입니다.
A모듈의 기능 변경으로 A모듈인지 판명하는 조건 분기가 추가됩니다. B모듈에서 기능을 추가하면서 가져다 쓴 Common 모듈의 기능은 사실 C모듈을 위한 것 일지도 모릅니다.

▲ 모듈의 기능 변경으로 변경된 Common 모듈

과정이 반복되다보면, Common 모듈은 비대해지고 Common 모듈에 대한 의존성이 높아질 것입니다. A모듈을 수정하게 되면 다른 모듈에도 영향이 나타나게 됩니다. 각 모듈의 로직을 변경하고 싶어도 이미 너무 많은 것을 Common 모듈에 의존하고 있어 분해하기도 힘든 상황이 상황이 되어 버릴 것 입니다.

기능이 변경 됨에 있어 특정 모듈만을 위한 조건 분기가 추가되어 버린다면 더 이상 공통 로직이 아니게 됩니다.
유즈 케이스를 판정하는 조건 분기를 계속 구현하고 싶지 않다면, 공통로직이 아님을 알게된 시점에 코드를 분리하는 것이 좋아보입니다.

일견 같은 비즈니스 로직이라고 생각하였던 로직일지라도,
비즈니스에 대한 이해도가 높아지면서 서로 다른 로직이 필요하다는 것을 뒤늦게 인지하게 되는 경우도 있다고 합니다.

저희는 Common 모듈에 대한 의존성이 높아지는 것을 방지하고, 각 모듈이 각 모듈만의 책임을 질 수 있도록 비즈니스, 도메인 로직은 각 모듈에 작성하기로 하였습니다.
Common 모듈에는 모든 모듈에서 사용할 수 밖에 없는 Type, Util등의 내용만을 작성하기로 하였습니다.

참고

---

https://techblog.woowahan.com/2637/
(도서) 내 코드가 그렇게 이상한가요? - 센바 다이야