Clean Architecture 와 의존성 이야기

KEH·2023년 4월 5일
0
post-thumbnail

문득 프로젝트를 진행하며 Clean Architecture에서 의존성에 대한 의문이 들었습니다. 이와 관련된 이야기를 풀어가볼까 합니다.

사진과 같이 Clean Architecture에서 data 계층과 presentation 계층은 domain 계층에 의존하고, domain 계층은 어디에도 의존하지 않는 독립적인 계층 입니다.

화면에 새로운 정보를 보여주기로 하여 기존 API에서 Response data에 데이터가 추가되었습니다.

저는 다음과 같은 상황일 경우 프로젝트 상에서 어느 부분에 수정이 발생할지 생각해보았습니다.

  1. data 계층에 있는 response data 클래스에 변수가 추가됩니다.
  2. data 계층의 response data 클래스와 매핑되는 domain 계층의 data 클래스도 변수가 추가됩니다.
  3. data 계층의 data 클래스와 domain 계층의 data 클래스를 mapping 하는 mapping 클래스가 수정됩니다.
  4. Activity 또는 Fragment 에서 새롭게 추가된 데이터에 대한 추가 작업이 진행됩니다.

이 순서대로 진행이 되면 data 계층의 변경으로 인해 domain, presentation 계층이 모두 영향을 받게 되는데, 이렇게 될 경우 presentation 계층과 domain 계층이 data 계층에 의존하는 것 아닐까요?




❌ 아닙니다!!

화면에 새로운 정보가 추가되기로 결정되기 위해서는 먼저 요구사항 이 발생해야 합니다. 즉, 비즈니스 로직이 추가/수정된다는 이야기입니다.

비즈니스 로직과 가장 관련된 계층은 domain 계층입니다.

비즈니스 로직이 수정되었기 때문에 API와 화면이 수정된 것이죠.

즉, domain 계층이 수정됨으로써 data 계층과 presentation 계층이 영향을 받은 것입니다.

이로써 domain 계층은 독립적이기 때문에 다른 계층에 의해 영향을 받지 않고, 영향을 줄 뿐이라는 Clean Architecture의 개념이 성립(?)됩니다🫠

  1. domain 계층의 Response data 클래스에 변수가 추가됩니다.
  2. 백엔드 개발자는 기존 API의 Response data를 수정합니다.
  3. API 수정 사항에 맞춰 data 계층의 Response data 클래스를 수정합니다.
  4. data 계층의 Mapper 클래스를 수정하여 data 계층의 Response data 클래스와 domain 계층의 Response data 클래스를 mapping 합니다.
  5. Activity 또는 Fragment 에서 추가 작업을 진행합니다.

위의 절차가 Clean Architecture에 맞는 순서라고 생각합니다.

요구사항이 발생한다는 것은 비즈니스 로직의 변경으로 시작된다는 점, 서버의 수정을 시작점으로 생각하지 않는 것이 중요한 것 같아요.




Clean Architecture를 공부하면서 저처럼 생각해본 분들이 있을 것 같아 제 경험을 나누고 싶었어요. 이 글의 의도가 잘 전달됐으면 좋겠는데 항상 글솜씨가 너무 아쉽습니다.

아 그리고 이 내용은 다른 글을 보고 이해했다기 보단 '저의 의견' 이라는 점 참고해주세요! 잘못 이해한 부분이라면 댓글이나 메일로 알려주시면 감사하겠습니다 !!

출처: https://giphy.com/출처: https://giphy.com/

profile
개발을 즐기고 잘하고 싶은 안드로이드 개발자입니다 :P

0개의 댓글