클린 아키텍처의 Layer 의존성에 대한 고찰

박규훤·2022년 4월 21일
0

이 포스트에서 다루는 내용은 개인적인 생각일 뿐, 명확한 근거가 있는 정답이 아닙니다.

쿤다 프로젝트 진행 중 Layer 간의 의존성 순서(?)에 대한 고민이 생겼다.

배경

프로젝트의 9개의 모듈로 아래 그림과 같은 구조로 되어 있다.

┌----------------------------------------------------------------------┐
|                                 app                                  |
|======================================================================|
|                  |   local   |   remote   |              |           |
|   presentation   ├------------------------┤   firebase   |   kakao   |
|                  |          data          |              |           |
├----------------------------------------------------------------------┤
|                                domain                                | 
|======================================================================|
|                                common                                |
└----------------------------------------------------------------------┘

Clean Architecture에 따라 domain, presentation, data 모듈이 존재하고, 프로젝트 전역에서 사용되는 common과 어플 구동을 위한 app 등 부가적인 Layer가 있다.

이 중, firebase 모듈은 FCM을 사용하기 위해 존재하고, kakao 모듈은 카카오의 로그인 기능을 위해 사용 중이다. (두 모듈을 서드파티라는 모듈로 묶을지도 고민중이다.)

현재는 domain에서 service interface를 만들고 firebasekakao에서 이를 구현하여 사용하고 있다.

firebase는 FCM으로 서버의 push 메세지를 받아서 flow로 domain에 반환해주고, kakao는 domain의 요청을 받으면 카카오톡을 열어 인증을 하고 인증 결과를 반환한다.
어떻게 보면, 이 두 모듈이 하는 역할이 데이터를 다루는 것이라고도 할 수 있을 것 같다.

domain에서 비즈니스 로직을 담당하고, 모든 데이터는 data에서 받아오도록 하는 것이 클린 아키텍처인데, domain에서 firebase와 kakao를 직접 참조하고 있는 것이 바람직한가? 라는 생각이 들었다.

계획

┌----------------------------------------------------------------------┐
|                                 app                                  |
|======================================================================|
|                  |   local   |   remote   |   firebase   |   kakao   |
|   presentation   ├---------------------------------------------------┤
|                  |                       data                        |
├----------------------------------------------------------------------┤
|                                domain                                | 
|======================================================================|
|                                common                                |
└----------------------------------------------------------------------┘

따라서, 위의 형태로 firebasekakao 모듈을 data 아래로 이동하고, repository의 data source 형태로 변경하고자 한다.

시도 해보고, 나중에 생각 나면 결과에 대해 다시 포스팅하겠다. (더 좋은 구조인지? 확장과 수정이 더 편해졌는지?)

profile
개발팀의 소방수

0개의 댓글