패키지 리팩토링

[hgo641]

각 안건에 대한 의견을 달아주실 때, 패키지 분리를 주장하시는 분들은 패키지간 의존성 방향도 함께 말해주세요.
ex) share패키지를 trip 패키지와 분리하고 싶다. 의존성 방향은 share -> trip으로 단방향으로 설계하고 싶다. 그 이유는 ~~

---

안건

share패키지를 trip패키지와 분리한다.(현상 유지) vs trip패키지와 합친다.

현재 여행 공유와 관련된 코드들은 share패키지로 분리되어있습니다. 여행 공유 코드를 share패키지로 분리하는 게 좋을지, trip패키지로 합치는 게 좋을지 의견을 남겨주세요!

여행 공개 코드(community 패키지)를 trip패키지와 분리한다(현상 유지) vs trip패키지와 합친다.

첫 번째와 유사한 안건입니다~~ 분리 vs 분리X 의견을 남겨주세요!

그 외 분리하거나 합치고 싶은 패키지가 있다면 댓글로 남겨주세요.

[LJW25]

1. 분리한다 (현상 반만 유지)
   패키지를 분리하되, trip에서 sharedStatus를 변경하는 api를 trip에 두는게 적절하지 않을까 합니다.
   의존성은..어려운데...🙃 어쩔수없이 양방향이 되어야하지 않나..까지 생각했다가 그냥 아무 생각 없어짐. 양방향 좀 아닌것같네요. 그냥 합치시죠..

2. 분리하지 않는다
   패키지 분리 안한다면 자연스럽게 공개 코드도 분리하지 않아야 하지 않을까 합니다.

3. 기타
   사실 전 share 자체가 분리 해야한다 안해야한다 보다는 share과 publish(community)가 통일만 되면 좋겠다는 의견입니다!

[mcodnjs]

분리하지 않는다. 근데 이거 진짜 머리가 깨지겠네요 ..
뭘 어떻게 설명해야할지도 잘 모르겠습니다.

Trip 패키지에 모든걸 넣습니다. (원래 Trip은 비대한 법입니다 ㅎ)
현재 SharedTrip, PublishedTrip은 사실상 Trip의 변화로 모든게 결정납니다.

1. Trip의 SharedStatusType을 업데이트했을 때
2. Trip의 PublishedTripType을 업데이트했을 때
3. Trip을 삭제했을 때 SharedTrip과 PublishedTrip 삭제

Trip은 statusType까지만 가지고 있고, SharedTrip과 PublishedTrip에서 Trip을 객체참조하는 방향으로 생각했습니다.
SharedTrip -> Trip, PublishedTrip -> Trip

위처럼 구현한다면, TripService에서 SharedTripRepository와 PublishedTripRepository를 가져야하죠
그렇지만 SharedTripService나, PublishedTripService는 TripRepository를 가질 필요가 없습니다. 맞나요 ?
(PublishedTripService는 현재 CommunityService 라고 생각하시면 좋을거 같습니다. 이 네이밍도 헷갈리네요..)

---

이상 부족한 제 발언이었습니다.
그외!

• expense는 이대로 가도 괜찮은가?
• 그리고 레거시 코드가 아직 남아있는거 같은데 패키지 정리하면서 같이 정리하면 좋을거 같습니다 ~!

[hgo641]

일단 같은 트랜잭션에 포함되는 애들을 패키지로 묶으려고 했습니다. 그래서 같이 조회되고, 같이 변경되는 애들은 하나의 패키지로 묶었습니다.

share패키지를 trip패키지와 분리한다.(현상 유지) vs trip패키지와 합친다.

1. 합친다.

sharedTrip이 조회될 때 항상 Trip도 조회해와야하고, Trip이 조회될 때 항상 sharedTrip(사실상 sharedCode가 되어버린)도 조회되기 때문에 둘은 같은 패키지로 합치자! 파입니다.

여행 공개 코드를 trip패키지에서 분리한다(현상 유지) vs 분리하지 않는다.

2. 분리한다. (의존성 방향 : PublishedTrip -> Trip)

우선 PublishedTrip은 항상 Like와 함께 조회되기 때문에 둘은 같은 패키지안에 있는 게 좋겠다고 생각했습니다.

PublishedTrip이 Trip의 생명주기에 영향을 받는 것도 맞고, Trip의 내용에 변화가 생기면 PublishedTrip의 내용도 변화가 생기는 것은 맞지만, Trip이 조회될 때 PublishedTrip이 함께 조회되진 않습니다. Trip에 변화가 생기는 순간과 Like에 변화가 생기는 순간은 확연히 다르기에 분리해야겠다고 생각했습니다.

+ PublishedTrip이 Trip을 객체참조 대신 ID참조를 하게 변경하자

그 외 분리하거나 합치고 싶은 패키지가 있다면 댓글로 남겨주세요.

근데 보다보니까 share이랑 publish보다 expense이게 더 굉장한 녀석입니다. 어떻게 분리하면 좋을지 감도 안옵니다. 그렇다고 trip이랑 expense를 합치기엔 일 겁나 커집니다.

아직도 이거다!하는 해결책은 생각안나지만 일단 결론은 다음과 같습니다.

• Expense 도메인 객체는 trip으로 옮긴다. (Amount값객체도 trip으로 이동...)
• expense 패키지의 이름을 가계부(영어이름미정)으로 변경한다.
• 가계부 패키지는 trip에 단방향으로 의존한다. (가계부 -> trip)

현재 Expense도메인 객체로 인해 trip <->expense의 양방향 참조가 일어나고 있으므로, 단순히 비용을 표현하는 데 사용하는 Expense와 Amount는 trip안으로 몰고, 가계부를 표시하기 위한 통계 관련 도메인&로직만 가계부 패키지로 묶자는 레전드 꼼수 작전입니다.

[jjongwa]

share패키지를 trip패키지와 분리한다.(현상 유지) vs trip패키지와 합친다.

2. 분리한다.

sharedTrip이 tripId만 가지고 있게 간접참조로 바꾸면 해결됩니다.

여행 공개 코드를 trip패키지에서 분리한다(현상 유지) vs 분리하지 않는다.

2. 분리한다.

여기도 trip를 가지고 있게 간접참조로 바꾸면 해결

그 외 분리하거나 합치고 싶은 패키지가 있다면 댓글로 남겨주세요.

현재 패키지 상태에서 합치고 싶은 부분은 없고 요점만 말하자면
서로 다른 패키지에 존재하는 도메인 객체는 간접참조로 의존성을 끊어주자
입니다.

그러한 관점에서 item과 DayLog은 생명주기가 다르기 때문에 서로 다른 패키지로 분리하고,
그에 따른 Place도 Item 패키지에 넣거나 아예 다른 패키지로 분리해도 좋다고 생각합니다.

Like랑 Community도 다른 패키지로 분리하자! 는 의견이구
LikeCountroller의 updateLikeStatus나 ExpenseController의 getExpenses 같은 메서드는 TripController에 있어도 좋지만 굳이 옮길 필요는 없다는 입장입니다.

[waterricecake]

share패키지를 trip패키지와 분리한다.(현상 유지) vs trip패키지와 합친다.

2.분리한다

홍고가 말한 트랜잭션 별로 합치는 것도 좋겠지만 지금 trip의 패키지가 너무 크지않나... 결국우리 도메인은 서로 연관될 수 밖에 없는데 다 하나하나 생각하면 결국 패키지가 너무 커질꺼 같습니다.

여행 공개 코드를 trip패키지에서 분리한다(현상 유지) vs 분리하지 않는다.

2. 분리한다
   share와 같은 이유이기도 하고 또 이오의 말처럼 분리하는데 통일성이 있어야 한다고 생각하기 때문에 분리해야하지 않나 생각하고 있습니다.

그 외 분리하거나 합치고 싶은 패키지가 있다면 댓글로 남겨주세요.

저는 최대한 분리하고 싶습니다. 다른 이유보다는 trip패키지만해도 지금 거대한데 나머지 하나나 다 합치면 너무 trip이 커질 것 같습니다.

또 expense는 특히 분리하자는 입장입니다. 같은 트랜잭션이기에 묶자는 의견이 있던데 경비 조회할 때 다(내여행, 공유, 공개) expense패키지의 ExpenseService를 사용하는데 이것까지 보면 트랜젝션을 기준으로 묶기 보다는 기능별로 나는 것이 좋을 것 같다는 생각이 듭니다.