[Fix, Refactor]: 의존성 사이클 해결(User, Praise, Reliability)

[jihwan2da]

Issue number

• resolved User, Reliability, Praise의 의존성 사이클 이슈 #128

작업 사항

User -> Praise, Reliability로 단방향으로 의존관계를 설정함으로써 의존성 사이클을 해결

• 기존 ORM의 연관관계 User <-> Praise, Reliability(연관관계 주인)에서 User(연관관계 주인) -> Praise, Reliability로 수정하였습니다.
• User를 조회할 때 Praise와 Reliability가 같이 조회 되어 쿼리가 총 3번 나가는 문제를 해결하였습니다(DB latency 문제도 자동으로 해결).
• 이에 따른 추가로 해야하는 작업들
• Praise, Reliability의 user_id 포렌키 삭제
• User의 praise_id, reliability_id 포렌키 추가
• 기존 회원들 위의 포렌키 작업 이후 데이터 정합성 유지

User와 Praise, Reliability의 경계를 재설정

무슨 이유인지는 잘 기억나지 않지만(아마 Praise, Reliability가 독립적으로 행위를 하는 것이 어울리다고 생각한 듯??) 이전에는 User와 Praise, Reliability를 하나의 도메인 경계로 설정하지 않고 각각 독립적으로 경계를 설정하였습니다.
따라서 User와 Praise, Reliability가 각각 다른 패키지에 있었고, 루트 도메인으로서 동작하고 있었습니다. 그렇게 독립적으로 경계를 나눴으면 User와 Praise, Reliability가 강한 의존관계를 가지고 있지 않아야 했습니다. 일부분은 그런 노력이 있었습니다.(ex. User 생성 이벤트로 Praise, Reliability 생성, 다른 이벤트(그룹생성, 그룹 멤버들 평가)로 인해 직접 Praise, Reliability 반영)
하지만 User, Praise, Reliability가 각각 서로 직접 참조하고 있었고, 서로 참조를 활용하는 코드들이 많이 발생하고 있었습니다.
그 결과 도메인 끼리의 의존성 사이클 뿐만 아니라 패키지의 의존성 사이클이 많이 발생하였고 따라서 데이트의 흐름이 한 방향으로 흐르지 않았고 중구난방이었습니다. 따라서 복잡해진 도메인의 방향성을 바로잡고자 아래와 같은 2가지 해결방법을 생각하였습니다.

i. 직접 참조를 제거하고 User는 Praise 및 Reliability의 존재를 모르게 한다.
ii. User, Praise, Reliability를 하나의 경계로 두자.
위 방법 중 2번 방법으로 해결하기로 하였습니다. 이유는 다음과 같습니다.

i. User, Praise, Reliability의 생명주기는 정확히 같다.
User가 생성될 때 Praise, Reliability가 생성되고 User가 삭제될 때 Praise, Reliability 또한 삭제됩니다. 이런 정확히 같은 생명주기를 갖는 객체들은 하나의 경계(User를 루트 도메인으로 두고 자식 도메인으로 Praise, Reliability)로 설정하는 것이 관리하기 편하다고 생각하였습니다.
ii. 너무 많이 발행되는 이벤트를 줄일 수 있다.
iii. Praise, Reliability의 Repository를 생성을 할 필요가 없어진다.

이에 따른 추가로 해야하는 작업들

• Reliability, Praise 패키지 User로 합치기
• Reliability, Praise가 독립적으로 처리한 행위 User를 통해서 처리되도록 변경
• Reliability, Praise 이벤트 컨슈머 User 컨슈머가 처리하도록 변경
• 그에 따른 테스트 코드 변경..

DDL

alter table users add praise_id bigint after id;
alter table users add reliability_id bigint after id;

## 배치 작업 후

alter table reliability drop foreign key reliability_ibfk_1;
alter table reliability
    drop column user_id;

alter table users
    add constraint fk_users_to_praise foreign key (praise_id) references praise (id);

alter table users
    add constraint fk_users_to_reliability foreign key (reliability_id) references reliability (id);

[twoosky]

오 의존성 사이클을 해결한다는게 클린 아키텍처와 같이 의존성이 모두 한 방향을 바라보도록 하는건가요? 한 방향을 바라보도록 설계하면 MSA 도입 시 서비스별로 서버를 분리할 때 좋을거 같아요 👍

DE latency 원인이 외래키가 대상 테이블(Praise, Reliability)에 존재해 User 조회 시 Praise, Reliability가 즉시로딩 되어서 그런가요?