Replies: 2 comments 5 replies
-
|
지금은 확실히 좀 불편하니 부나의 의견대로 바꿀 필요성이 있는 것 같아요! 일단 부나가 제안한 방식으로 바꾸고 추후에 더 불편하다면 그때 바꾸도록 해요 |
Beta Was this translation helpful? Give feedback.
-
|
토마스도 동의하신다면 다같이 리팩토링 해봐요 😝 |
Beta Was this translation helpful? Give feedback.
-
|
동의합니다 |
Beta Was this translation helpful? Give feedback.
-
|
또한 패키지명을 evenst가 아닌 eventList 이런식으로 이벤트 목록이다 라는것을 명시하는게 가독성이 더 좋은것 같아요 개인적으로 |
Beta Was this translation helpful? Give feedback.
-
|
화면을 말하는 겁니다 |
Beta Was this translation helpful? Give feedback.
-
|
저도 화면은 events보다 eventList가 더 명확하다고 생각해요! |
Beta Was this translation helpful? Give feedback.
-
|
동의합니다 |
Beta Was this translation helpful? Give feedback.
-
현재 패키지 구조는 프로젝트 구조를 파악하기 어렵다는 문제가 있다고 생각합니다.
Data 패키지
현재 data 패키지 구조는 위와 같습니다.
처음에는 위와 같은 도메인형 구조가 좋아 보였지만 아래의 경우가 발생하면서 개선이 필요하다고 느꼈습니다.
도메인형 vs 계층형
Event와 관련된 데이터 모델을 한 패키지에 모으면서 EventCategory와 같은 별도의 클래스도 한 곳에 모이게 됩니다.
문제는 EventCategory를 Event 패키지의 Repository 뿐만 아니라, 다른 Repository에서도 접근해야 하는 상황이 발생할 수 있다는 것입니다.
따라서, 도메인형에서 계층형 구조로 변경하는 것을 제안드립니다.
계층형 구조는 DTO(Response, Request), Model, Repository를 각 패키지로 만들어서 하위에 모든 클래스를 관리하는 방식입니다.
도메인형 구조도 충분히 장점이 있다고는 생각하지만, 프로젝트 규모가 작고 조금 더 일관성 있는 구조를 위해 계층형으로 변경해보는 것은 어떨까요?
Presentation 패키지
다음은 Presentation 패키지입니다.
Presentation 패키지는 main 화면 내에 3개의 fragment가 포함되어 있다면, main 패키지가 fragment 패키지를 포함하고 있는 구조입니다.
하지만 위 사진을 보시면 알 수 있듯이, Fragment에서 관련된 다른 Activity가 생기면서 자연스럽게 depth가 깊어진다는 것을 알 수 있습니다.
이러한 문제를 해결하기 위해 Presentation 패키지는 도메인형 구조로 변경하는 것을 제안드립니다.
한 화면별로 presentation 하위에 패키지로 분리하면, 지금보다 특정 화면을 훨씬 찾기 쉬워질 수 있다고 생각합니다.
Beta Was this translation helpful? Give feedback.
All reactions