ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 모듈간 의존성 개선 및 정리 작업
    실무에서 알게된 내용 2022. 6. 30. 10:08

    Edge API 전환 작업을 진행하며, 추가로 모듈 간 의존성을 개선 및 정리하는 작업을 조금 진행했었다. 아직, 완벽하다고 말할 수 있는 상태는 아니지만 해당 작업을 진행하며 개인적으로 고민했던 사항들을 아래와 같이 정리해 봤다.

     

    참고로, 내가 담당하고 있는 서비스의 모듈은 아래와 같이 총 7개로 구성돼 있다.

    • internal api
    • external api
    • service
    • domain
    • common
    • common-web
    • client

     

    1. api 모듈(internal/external)이 의존하고 있는 모듈 (as-is: 5개, to-be: 4개)

    • common
    • common-web 
      • api 모듈(internal/external)에서 각각 선언해서 사용하고 있던 request/response 객체를 common-web 모듈로 이동시킴
        • common-web 모듈 한 군데에서만 관리하기 위함 -> 실수 가능성 낮아짐
        • 이로 인해 api 모듈에서 swagger-annotations 의존성을 제거할 수 있었음
    • service
    • domin -> service 모듈을 통해서만 접근 가능하도록 변경하고 싶었지만, 기존 기능이 영향을 받아서 일단 보류
    • client 모듈 의존성 제거 -> client 모듈은 service 모듈을 통해서만 접근 가능하도록 변경
      • 이로 인해 api 모듈에서 openfeign 의존성을 제거할 수 있었음
      • 장점 : 신규 FeignClient 등록을 service 모듈 한 군데에서만 하면 됨 (기존에는 api 모듈 두 군데에서 해야 했음) -> 실수 가능성 낮아짐 

     

    2. service 모듈이 의존하고 있는 모듈 (as-is: 2개, to-be: 3개)

    • common
    • domin
    • client 모듈 의존성 추가
      • client 모듈은 service 모듈을 통해서만 접근 가능하도록 변경함 
      • 이로 인해 service 모듈에 openfeign 의존성을 추가해야 했음 

     

    3. common-web 모듈이 의존하고 있는 모듈 (as-is: 1개, to-be: 2개)

    • common
    • domin 모듈 의존성 추가
      • api 모듈(internal/external)에서 각각 선언해서 사용하고 있던 request/response 객체를 common-web 모듈로 이동시켰기 때문 
        • request 객체를 service layer에 넘기기 전 domain 객체로 변환하는 작업을 수행하고 있는데 이것 때문에 domain 모듈 의존성이 필요했음
        • response 객체를 만드는데 domain 객체(+ 여러 도메인의 요청 결과를 aggregation 한 domain 객체)가 사용되기 때문에 domain 모듈 의존성이 필요했음 
        • api 모듈에 있었던 request/response 객체를 common-web 모듈로 이동시키면서 common-web 모듈에 swagger-annotations 의존성을 추가해야 했음

     

     

    댓글

Designed by Tistory.