View

300x250

클린 아키텍처를 적용하기 위해 기존의 프로젝트를 리팩토링 하고있다.

기존에는 각 기능(뷰) 별로 폴더 내에 presentation, domain, data 세 가지 layer를 모두 배치하고, 각 계층 내에 필요한 폴더를 따로 만들어서 관리하고 있었는데, 여러 기능에서 공유되어야 하는 usecase가 하나의 기능 폴더에 귀속되어 있어 다른 기능쪽에서 끌어서 사용해도 되나? 라는 걱정이 많이 되었었는데, 요런 부분들을 타파하기 위해 완전 구조 개선을 시도하고 있다.

개선을 시도한 내용은 아래와 같다.

  1. 모든 폴더에 따로 놓여있는 모델 → Entity로 이름을 바꿔 한 폴더에서 관리하기
  • 동일한 개념이지만 여러 개로 구현되어있는 모델은 하나로 정리하기
  1. 여기저기 흩어진 usecase를 한 폴더에서 관리하기
  • 명명 컨벤션 통일하기, 동일한 역할의 usecase는 하나로 통일하기
  1. repository들을 한 폴더로 모으고, 정리하기

구조를 개선하려고 변경을 적용하면서 확실히 느낀 점은, 기존의 폴더구조와 구현 방식에 문제가 많았다는 것이다.

  • 동일한 기능이 3개 넘게 중복 구현된 경우도 있었고
  • 동일한 모델을 2가지 방식으로 (직접 구현 / freezed 로 구현) 작성해서 호환이 안되는 경우도 있었다.
  • 하나의 코드 변경에 대해 너무 많은 에러가 뜬다! 아마도 요 부분은 구현에 있어서 의존성의 분리가 덜 적용되어서 그런 것 같다. 하나의 파일 변경에 최대한 적은 오류가 뜰 수 있도록 더 많은 개선이 필요할 것 같다.

현재 entity, usecase에 대해 정리를 해두고 repository 쪽을 수정 중인데, 확실히 “필요한 로직이 뭔지 정의해두기” ⇒ “실제로 필요한 로직들을 구현하기” ⇒ “화면에 로직 띄우기” 순서로 작업을 진행할 수 있기 때문에 가능한 방식인 것 같다. 필요한 기능을 먼저 정의하고 로직 짜기! 요게 클린 아키텍처를 적용했을 때의 큰 장점이고, 리팩토링을 하면서 요 부분들의 효능을 느끼고 있는 것 같다.

레포지토리 쪽도 얼른 수정하고 다른 계층들의 리펙토링도 진행해봐야겠다!

[ 변경 전 ]

Untitled.png

[ 변경 후 ]

Untitled.png

320x100
Share Link
reply
반응형
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31