프로젝트 아키텍처 관련 논의사항

[jkde7721]

패키지 의존성

패키지 간 의존성 사이클을 제거하자

[참고 영상] 우아한 객체지향 - 의존성을 이용해 설계 진화시키기

• 패키지 구분 기준: 같이 변경되는 코드는 같은 패키지에, 따로 변경되는 코드는 다른 패키지에
• 영상의 내용을 요약하자면 패키지 간 의존성 사이클은 제거하는 것이 좋으며 더 나아가 엔티티 간 연관성이 떨어진다면 객체 참조(직접 참조)가 아닌 엔티티의 PK를 참조(간접 참조)하는 것이 좋음
• 패키지 의존성 사이클을 제거해야 하는 이유: 클래스 간 연관관계든, 의존관계든 A → B 형태의 의존성이 존재할 때 B의 구현 내용이 변경된다면 A의 구현 내용도 변경될 가능성O, 반면 B는 A를 의존하지 않기 때문에 A의 내용이 변경되더라도 B에게는 영향X
  but 만약 패키지 A와 B 사이에 의존성 사이클이 돈다면 A가 변경되더라도 B가 변경되더라도 서로에게 영향을 미침 → 변경의 범위, 즉 변경의 영향력 매우 커짐
• 엔티티 간 연관성을 고려하여 참조 대상을 정해야 하는 이유: 예를 들어 우리의 프로젝트에서 Message 엔티티의 내부에서는 Profile, Workspace 클래스 객체를 직접 참조하고 있음(연관관계, Message에서 Profile, Workspace로 이동할 수 있는 영구적인 경로). 만약 연관성이 떨어진다면 객체 참조가 아닌 엔티티의 PK인 Long형 변수 profileId, workspaceId를 내부 필드로 가지고 있는 것이 좋음 → repository를 통한 탐색 가능(약한 결합도)

1. 연관관계는 탐색가능성을 의미하기 때문에 객체 1개를 타고 타고 타고 모든 다른 객체에 접근할 수 있음 ex. 우리의 프로젝트에서 schedule → workspace → profile → user까지 하나의 트랜잭션 내에서 Lazy Loading으로 모두 접근 가능
2. 객체 그룹의 조회 경계가 모호 즉 어디까지 읽어야 하는지 가이드 부재

연관성을 판단하는 기준

고려할 질문

• 수정 시 도메인 규칙을 함께 적용할 경계는?
• 트랜잭션 경계는 어디까지인가?(객체 참조로 하나의 트랜잭션 내에서 조회해올 객체는 어디까지인가?) 어떤 테이블에서 어떤 테이블까지 하나의 단위로 잠금(Lock)을 설정할 것인가?

간단한 규칙

1. 함께 생성되고 함께 삭제되는 객체들을 함께 묶어라
2. 도메인 제약사항을 공유하는 객체들을 함께 묶어라
3. 가능하면 분리하라

결론

• 현재 JPA 엔티티 양방향 연관관계에 의해 발생하는 패키지 의존성 사이클을 제거하자!
• 엔티티 간 연관성 정도를 파악하여 약한 결합도를 가지도록 하는 것도 좋긴 한데 지금 단계에서는 조금 무리라고 생각됨

➡️ 따라서 패키지 의존성 사이클 정도만 없애자! 몇몇 코드를 보면 패키지 간 의존성 사이클이 도는 이유가 JPA 양방향 연관관계에 의한 것도 있지만 API 구현이 잘못된 위치에 있기 때문에 발생하는 경우가 있음. 일단 객체 간 협력 관계(누가 메시지를 보내고 받는지)를 파악하기 좀 힘들 것 같아서 일단은 N → 1 방향으로 패키지 의존성 잡고 가기로 하고, 복잡한 조회 로직을 처리하기 위해 어쩔 수 없이 양방향 연관관계가 필요한 경우도 생길 수 있는데 일단은 아래 그림을 기준으로 구현하기

현재 패키지 간 의존성 상태 (TimecardReq는 제외)

• 패키지 간 의존성 사이클 총 5개
• 위의 양방향 의존성이 있는 도메인들은 함께 생성되고 함께 삭제되지 않음, 도메인 제약사항 공유X ➡️ 양방향 관계 → 단방향 관계로

최종 패키지 간 의존성 상태

ex. 현재 workspace 도메인을 보면 StaffWorkspaceController 클래스에서 workspace → schedule로의 패키지 의존성 발생 ⇒ API 구현이 잘못된 위치에 있기 때문, 즉 해당 API 구현은 schedule 도메인 내부에 있어야 함
ex. StaffProfileRepositoryImpl 클래스에서 profile → schedule, profile → workspace로의 패키지 의존성 발생 ⇒ 해당 의존성 발생시키는 메소드 findAllByWorkspaceIdAndDateTime를 ScheduleRepositoryImpl 클래스로 옮겨야 함

---

패키지 구조

• 각 도메인 내의 패키지들 간에도 계층이 나뉨 ⇒ web(presentation), application(service), repository(domain) 계층으로 나뉘는데 현재의 각 도메인 내 패키지 구조는 각각의 패키지들이 어느 계층에 속하는지 명시적으로 알 수 없음
• 약간 오버일 수도 있지만 프로젝트가 복잡해지면 web(presentation) → application(service) → repository(domain)로 먼저 패키지 나누고 들어가는 것도 천천히 고려해보기

대략적인 패키지 구조

결론

각 도메인 내부 패키지 구조는 천천히 고려해보고 나중에 한번에 바꾸는 걸로

---

계층 간 매핑 관계

• 원래는 1개의 controller → 여러 service 의존, 1개의 service → 1개의 repository 의존 ➡️ controller는 적절한 요청을 받아서 이를 service에게 전달하는 로직만 수행해야 하는데, 여기서 여러 service에 의존하게 되면서 비즈니스 로직에도 관여하게 됨(요청에 따라 어떤 비즈니스 로직이 좋을지 controller가 선택해야 함) ➡️ 적절한 요청에 대해 단순히 1개의 service에게만 비즈니스 로직을 위임하도록 하는 것이 좋지 않을까?
• OSIV를 아직 끄지는 않았지만 끈다고 생각했을 때 사용자 요청에 대한 트랜잭션 시작점이 하나이고 끝나는 지점이 하나인게 더 명확함, but 만약 여러 service에 의존한다면 controller의 하나의 메소드 내부에서 트랜잭션 시작점과 끝나는 지점이 여러개이기 때문에 혼동될 수 있음
• OSIV를 키면 controller 요청~응답까지 하나의 DB connection이 유지되는 반면,
• 끄면 service의 @Transactional당 하나의 DB connection이 유지됨 ➡️ 1개의 controller가 여러개의 service 의존하는 경우 하나의 사용자 요청에 대해 여러 번의 DB connection 설정 과정이 필요하게 되는데, 만약 3번의 DB connection 설정이 필요한 상황에서 2번째 connection을 얻지 못하면 응답까지의 시간이 오래 걸림
• 외부 API 호출하는 service(ex. FirebaseCloudMessageService)는 도메인 service(ex. StaffMessageService)에 포함되면 안됨 ➡️ 트랜잭션과 무관한 작업이 트랜잭션에 포함되는 것이기 때문에 잘못하면 DB timeout 발생 ➡️ 이 경우에는 1개의 controller → 여러개의 service 의존 가능
• 1개의 service에서 여러개의 service, 1개의 repository 의존 ➡️ 잘못하면 service 간 사이클이 돌면서 시스템 오류 발생 가능 ➡️ 위에서 정의한 패키지 의존성 방향을 따를 때에만 해당 service 의존 가능, 만약 반대 방향이 나온다면 해당 API의 구현이 잘못된 위치에 있는 것임
• mapper는 controller에서만 의존
• -Util 클래스 내부에서는 repository 의존(실제로는 service와 비슷한 역할이나 모든 도메인에서 공통적으로 사용, 특히 profile 도메인은 auth 도메인을 제외한 모든 도메인에서 의존) ➡️ -Util 클래스는 controller에서 의존X, service에서만 의존 가능

결론

1개의 controller → 1개의 service(외부 API 호출하는 service는 여러개 의존 가능) → 여러개의 service(의존성 사이클 유의), 1개의 repository(도메인으로 묶인다면 여러개의 repository도 1개의 repository로 간주 ex. WorkspaceRepository, WorkspaceMemberRepository)

[jkde7721]

@jiyeoon00 구현하다 보니깐 repository 단에서는 위에서 정의한 패키지 의존성 방향을 적용하면 구현이 더 어색해지는 부분이 있어서 repository에서는 패키지 의존성 방향 딱히 고려하지 않아도 될 것 같아

예를 들어서 해당 workspace에 속하는 staff를 모두 조회해오고 싶을 때

(WorkspaceMember는 단순히 검색 조건이지 조회 대상이 아님)

Case1

select s from Staff s inner join WorkspaceMember wm on s.id = wm.staff.id where wm.workspace.id = :workspaceId

• Staff를 조회하므로 해당 쿼리 메소드 StaffProfileRepository 내부에 있음
• 이 경우 staff → workspace 패키지로의 의존성 발생 ➡️ 방향 적절X

Case2

select wm from WorkspaceMember wm join fetch wm.staff where wm.workspace.id = :workspaceId

• WorkspaceMember를 조회하므로 해당 쿼리 메소드 WorkspaceMemberRepository 내부에 있음
• workspace → staff 패키지로의 의존성 방향은 적절하나, 적절한 의존성을 위해 실제로 필요한 데이터(Staff) 이외의 것(WorkspaceMember)도 조회하는 일 발생 ➡️ 성능 상 이슈?

애초에 자바에서는 A가 B에 대한 객체 참조를 가지면 A → B 방향만으로의 연관관계가 생기는데(B → A는 불가) DB에서는 A가 B에 대한 FK를 가지면 A → B, B → A 양방향 모두 가능(by. 조인)해서 repository에서는 의존성 방향을 단방향으로 고정하는게 더 이상한 것 같아

결론적으로 repository에서는 위에서 정의한 패키지 의존성 방향 고려하지 말고 상황에 따라 적절한 쿼리를 선택하자 (이 경우에는 Case1)
(즉 테이블 접근방향으로 Staff → WorkspaceMember 가능, 이렇게 구현하다 보면 repository에서는 패키지 의존성 사이클이 발생할 수 있음)