1주차 과제 by hongs429 · Pull Request #27 · hanghae-skillup/redis_1st

hongs429 · 2025-01-11T20:19:34Z

제목(title)

멀티모듈 구성 및 API 구현

작업 내용

이번 PR에서 진행된 주요 변경 사항을 기술해 주세요.
코드 구조, 핵심 로직 등에 대해 설명해 주시면 좋습니다. (이미지 첨부 가능)

멀티모듈 구성
- 의존관계
  - presentation -> application -> infrastructure
  - application -> domain
  - infrastructure -> domain
- application 모듈과 domain 모듈은 비즈니스 로직의 핵심만을 다루며, 외부의 종속성을 제거.
- 각 모듈의 의존관계는 layered architecture의 흐름을 유지.
테이블 설계
- 영화, 상영관, 좌석, 상영 정보 등 주요 테이블 설계 및 관련 데이터 초기화.

발생했던 문제와 해결 과정을 남겨 주세요.

과제를 해결하며 발생했던 문제와 해결 과정을 상세히 기술해 주세요.

문제 1 - 멀티 모듈 구성의 복잡성

해결 방법 1:
Gradle(전역) 설정과 Gradlew 설정 충돌 문제로 인해 빌드 실패. 전역 Gradle을 삭제하고 Gradlew를 기준으로 통일하여 해결.

문제 2 - Port-Adapter 패턴 적용 시 각 모듈 간 인터페이스 설계의 어려움

해결 방법 2:
상위 모듈(application)이 하위 모듈(infrastructure)을 알지 못하도록 인터페이스를 정의.
하위 모듈(infrastructure)에서 인터페이스를 구현하여 분리.

문제 3 - Application 모듈에서 외부 기술의 의존도를 제거하는 방법 고민

해결 방법 3:
Application과 Infrastructure 모듈 모두 Domain을 참조하도록 설계.
이를 통해 Infrastructure의 외부 기술(entity, JPA)을 Application이 알지 못하도록 분리.

이번 주차에서 고민되었던 지점이나, 어려웠던 점을 알려 주세요.

과제를 해결하며 특히 어려웠던 점이나 고민되었던 지점을 기술해 주세요.

**Transaction의 범위(OpenView)**를 Application 모듈까지 가져가야 할지 고민 중입니다. 현재 구조로는 적합하지 않은 것 같아 추가 조정이 필요합니다.
멀티모듈 구성 경험이 없어, 현재 작성한 build.gradle과 모듈 구성 방식이 적합한지 확신이 없습니다.

리뷰 포인트

리뷰어가 특히 의견을 주었으면 하는 부분을 기술해 주세요.

Application 모듈까지 Transaction 관리를 적용하는 게 맞는 방향일까요?
만약 맞다면, 현재 구조나 코드에서 어떤 변경이 필요한지 조언 부탁드립니다.
작성한 멀티모듈 구조 및 build.gradle이 적절한지 검토 부탁드립니다.

기타 질문

추가로 질문하고 싶은 내용을 작성해 주세요.

Port-Adapter 패턴을 적용하면서 코드량이 예상보다 많아졌습니다.
하지만 모듈 간 의존도가 감소하고, 각 모듈이 독립적으로 작업 가능해졌다는 점에서 효율적이라 느꼈습니다.
현업에서는 Port-Adapter 패턴을 많이 사용하는지, 그리고 제가 작성한 코드가 적절하게 구현된 것인지 궁금합니다.

- module 구분: presentation, application, infrastructure, domain - 각 모듈이 독립적으로 작업가능하도록 SRP 적용 - Port-Adapter 패턴으로 명확한 의존관계 설정 - 프로잭트 설명은 루트의 README.md 에 기재 - 각 모듈의 기능과 설명은 README.md 에 명확하게 기재 - 급하게 하다보니 커밋을 나누지 못했습니다. 대신, 그만큼 자세하게 README.md에 기재했으니 참고 부탁드립니다

hongs429 · 2025-01-11T20:21:36Z

제가 급하게 올린터라 커밋을 나누지 못했습니다.
그래도 리뷰가 편하도록 각 모듈에 README.md 파일을 만들었는데 해당 파일을 보시면 리뷰하는데 도움이 되실거라고 생각합니다.

루트와 각 모듈의 README.md 파일을 확인부탁드립니다!

- module 구분: presentation, application, infrastructure, domain - 각 모듈이 독립적으로 작업가능하도록 SRP 적용 - Port-Adapter 패턴으로 명확한 의존관계 설정 - 프로잭트 설명은 루트의 README.md 에 기재 - 각 모듈의 기능과 설명은 README.md 에 명확하게 기재 - 급하게 하다보니 커밋을 나누지 못했습니다. 대신, 그만큼 자세하게 README.md에 기재했으니 참고 부탁드립니다

- CinemaCommandAdapter 에 TODO 남김(exception 처리를 위한 공통 모듈 필요성) - 각 모듈 별로 독립적인 cinema 생성 코드 작성

ann-mj

안녕하세요~ 1주차 과제를 진행하시느라 고생많으셨습니다.

[전체적인 피드백]

외부에서 domain 에 대한 의존도를 최대한 제거하시려고 설계하신 모습이 느껴졌고, 좋았습니다.
특히, 모듈 간 순환참조가 없게 잘 설계해주신 것 같습니다!

[질문에 대한 답변]

Application 모듈까지 Transaction 관리를 적용하는 게 맞는 방향일까요?
- 생각하시는 장점이 어떤게 있을지 의견주시면 좋을 것 같아요!
- 하나의 application 안에서 여러개의 infrastructure가 있을 때에만 필요할 것 같다고 생각합니다.
- 일반적으로는 infrastructure 레벨에서만 관리하는 것으로 알고 있습니다.
현업에서는 Port-Adapter 패턴을 많이 사용하는지,
- 제 회사에선, port-adapter 까지 세부적으로 나누진 않았습니다. 그냥 팀 내에서 코드리뷰를 주기적으로 하면서 계층간 서로 의존도가 없도록 관리하는 편입니다. 하지만, 계층 내에서도 하나의 port 를 통해 여러 adapter가 존재해야 하는 케이스가 있을 때는 유사하게 interface 로 설계해서 구현할 때도 있었습니다.
멀티 모듈을 잘 이해하고 여러 에러들이 있었을텐데 잘해주신 것 같습니다!! 👍

ann-mj · 2025-01-12T13:06:19Z

module-presentation/src/main/resources/db/migration/V1__CreateInitTable.sql

+    updated_at  datetime(6)  null,
+    created_by  binary(16)   null,
+    updated_by  binary(16)   null,
+    constraint fk_seat_cinema foreign key (cinema_id) references cinema (cinema_id)


실무에서는 FK 참조 무결성으로 인한 성능, 데이터 이관, 클렌징 작업 등의 편의성 때문에 FK를 걸지 않은 경우가 많은데,
이번 프로젝트의 경우에서도 데이터의 무결성이 중요하지는 않고, FK 가 반드시 필요하지는 않은듯 하여.. 제거해주셔도 좋을 것 같습니다.

Mysql 를 쓰는 이유가 innoDB의 장점을 가지고 가기 위해서 사용하는 것으로 알고 있는데요,

데이터 이관, 클랜징 작업은 FK로 얽혀 있는 경우 불편하다는 것은 이해했습니다.
다만 FK 참조 무결성이 성능에 저하를 일으키는 이유는 알겠지만, 꼭 필요한 경우와 필요하지 않은 케이스를 구분하는 게 조금 난해한것 같습니다.

지금 위의 sql에서 contraint만 빼서 관계만 제거하는 개념으로 거의 모든 RDB를 사용하나요?

애플리케이션 내부에서 관리를 하는 경우, 단순한 참조라면은 굳이 fk를 설정할 필요가 없다고 생각하구요.

혹 부모,자식관계에 있는 케이스 (댓글-게시글 처럼) 의 경우에는 fk 를 꼭 강제하기도 합니다.

요것도 정책적인 부분이긴 하지만 저희는 이번 프로젝트 내부적으로는 강한 제약이 없다고 봐주시면 될 것 같아요!

이해했습니다! 감사합니다!

ann-mj · 2025-01-12T14:11:23Z

README.md

+#### **의존관계**
+- `presentation` → `application` → `infrastructure`
+- `application` → `domain`
+- `infrastructure` → `domain`


모듈간 순환참조가 없이 잘 구현된 것 같습니다. 👍

ann-mj · 2025-01-12T14:14:49Z

module-domain/src/main/java/project/redis/domain/cinema/Cinema.java

+@Value
+@AllArgsConstructor(access = AccessLevel.PRIVATE)
+public class Cinema {
+    UUID cinemaId;


id들은 모두 unsigned int 형으로 될 수 있도록 long 또는 int를 사용해주세요~

넵! 수정하겠습니다!

ann-mj · 2025-01-12T14:38:53Z

module-application/README.md

+---
+
+#### **`ScreeningsQueryParam`**
+- 비즈니스 로직 수행에 필요한 파라미터를 캡슐화한 클래스.


바로 request 에서 get해서 사용하는게 직관적이지 않을까 생각이 들었는데요~
request 를 통해 param 을 캡슐화하면 어떤 장점이 있나요?

캡슐화라는 말은 조금 과한 것 같네요..ㅎ
그보다, presentation 모듈에서 client로부터 받는 요청이 변경되었을 때, application에서의 영향이 적다는 것을 이야기하고 싶었습니다.
사실 presentation에서 application으로 전달되는 파라미터는 어찌보면 동일하게 넘어갈 수 있겠지만,
협업하는 입장에선 하나의 요청이 각 모듈에서 전달되는 인자가 강하게 얽혀있으면
한 사람이 모두 수정을 해야하기 때문에 나누는게 좋다고 생각했습니다.
반대로 말해서 얽혀있지 않다면, 여러사람이 각 모듈을 수정 가능하다는 것을 어필하고 싶었습니다!

일하다보니 api spec이 너무 자주 변할때도 있어서 결합도를 낮추는 코드가 의미가 없어질 때도 있더군요.🥲

결합도를 낮추는 의도에서 좋은 접근이신 것 같습니다.
다음 주차부터 계속되는 endpoint들도 잘 설계해주신다면 파라미터가 무분별하게 추가되는 일도 막을 수 있겠네요! 변화에 항상 열려있는 코드를 짜는게 힘든데, 의도가 명확하셔서 좋네요 ㅎㅎ

항상 생각만 하다 실제로 구현해보니 초반에 조금 힘들긴했습니다...ㅎ
리뷰 감사합니다!

추가로,
Application 모듈까지 Transaction 관리를 적용하는 게 맞는 방향일까요? 에대한 답변

생각하시는 장점이 어떤게 있을지 의견주시면 좋을 것 같아요! 하나의 application 안에서 여러개의 infrastructure가 있을 때에만 필요할 것 같다고 생각합니다. 일반적으로는 infrastructure 레벨에서만 관리하는 것으로 알고 있습니다.

이 부분은 경험이 부족하다보니 잘 몰랐는데, '일반적으로는 infrastructure 레벨에서만 관리하는 것으로 알고 있습니다.'인지가 궁금했습니다. 실제로 지금 프로잭트에서 많은 관계를 물고 있는 상영시간표 CUD를 하다보니 말씀해주신게 맞다는 판단이 조금씩들고 있습니다.

감사합니다!!

ann-mj · 2025-01-12T14:40:27Z

module-infrastructure/README.md

+
+1. **외부 통신 및 기술 로직 담당**
+    - 데이터베이스, 외부 API, 메시지 큐 등 외부 시스템과의 통신을 처리.
+    - JPA, Flyway 등 구체적인 기술을 활용하여 데이터를 저장하고 조회.


Flyway 가 형상 관리를 하는 도구라고 알고 있는데요. 혹 해당 프로젝트에서 선택하신 이유가 있었을까요?

저는 모듈을 분리하고, 의존도를 낮추는 방향으로 개발을 하는 게
결과적으로 협업을 위한 것으로 판단했습니다. 이번 과제도 앞서 말한 것을 염두한게 아닐까 생각했구요.
플라이웨이는 제가 기존에도 많이 애용하게 되던 툴인데,
말씀하신 것처럼 형상관리 도구이면서도,

데이터베이스 구조나 코드 변경 이력을 추적하여 언제, 누가, 무엇을 변경했는지를 명확히 파악

validation, none 상태에서 팀원들이 동시에 작업하더라도 에러를 명시적으로 확인가능하여 수정하기 용이

데이터 베이스 변경 사항 관리 가능(테이블로도 확인 가능)
이라는 측면에서 사용해봤습니다.

docker의 볼륨으로 하는 것보다 익숙한 이유도... 한 목 했습니다..ㅋㅋ

복잡한 설정없이 편하게 사용할 수 있나보군요?

저희는 DBA가 따로 있어서 그분들에게 요청했었는데 JPA랑 같이 쓰면 편할 것 같은데, mybatis 로 쓰는 사람들도 잘 쓸수있을까요?

mybatis는 잘 모르겠습니다..ㅎ

설정은 그냥

의존성추가

yaml 파일에 "사용겠다", "해당 경로를 통해 쓰겠다" 정도라 편합니다.

파일을 만드는 규칙만 알면 쉬운것 같습니다(1년차인 저도 회사에서 그냥 설명듣고 바로 썼습니다)

개인적으로는 checksum으로 파일을 함부로 변경불가능하게 만들어서, 버전관리를 엄격하게 다루고 있다는게 좋은 것 같습니다.

에플리케이션 실행단계에서 flyway가 먼저 동작해서 hibernate가 validate하기 이전에 동작하는 걸로 알고 있는데,, 이 구조대로라면, mybatis는 버전관리 스크립트를 보고 설계하는 정도일 것이라고 생각되긴합니다!

늦은 시간인데도 리뷰를 해주셔서 정말 감사합니다!!ㅠㅜ

- 간단하게 application 테스트 코드 추가

- 각 모듈 별 테스트 환경 구축

- 최소한의 도메인 생성 시, 검증 로직 추가

@foreignkey

- 이번 프로잭트의 취지에 맞도록 foreign key 참조는 전부 제거 - flyway 로 foreign key 제거 후 이력 관리 - application 레벨에서 키를 관리 - application 레벨에서 키를 관리함을 명시적으로 설정 - foreignKey = @foreignkey(value = ConstraintMode.NO_CONSTRAINT) - 곁다리로 임시 데이터 생성 스크립트 주석 처리(지우긴 아쉬워)

hongs429 added 5 commits January 7, 2025 23:30

first commit

763580f

모듈 구성과 의존성 관계 적용

4514acf

도메인 정의 && 도메인 레벨의 관계 설정

c2b9f74

commitmm

10fb36b

github-actions bot added the 1주차 label Jan 11, 2025

hongs429 added 7 commits January 12, 2025 20:08

first commit

713e05b

first commit

c7b8096

도메인 정의 && 도메인 레벨의 관계 설정

5f0f369

commitmm

02e3555

git 정상화

146d9ed

feat(cinema) : create cinema

f816885

- CinemaCommandAdapter 에 TODO 남김(exception 처리를 위한 공통 모듈 필요성) - 각 모듈 별로 독립적인 cinema 생성 코드 작성

ann-mj reviewed Jan 12, 2025

View reviewed changes

hongs429 added 4 commits January 13, 2025 23:57

feat(cinema) : create cinema TC

9551e01

- 간단하게 application 테스트 코드 추가

fix(build.gradle) : update dependency

5c7d8b6

- 각 모듈 별 테스트 환경 구축

feat(domain) : create domain validation

2e0f48c

- 최소한의 도메인 생성 시, 검증 로직 추가

phyeran changed the base branch from main to hongs429 January 17, 2025 02:09

spartacontents deleted the branch hanghae-skillup:main January 17, 2025 03:19

spartacontents closed this Jan 17, 2025

spartacontents reopened this Jan 17, 2025

phyeran changed the base branch from hongs429 to main January 19, 2025 06:00

Conversation

hongs429 commented Jan 11, 2025

제목(title)

작업 내용

발생했던 문제와 해결 과정을 남겨 주세요.

이번 주차에서 고민되었던 지점이나, 어려웠던 점을 알려 주세요.

리뷰 포인트

기타 질문

Uh oh!

hongs429 commented Jan 11, 2025

Uh oh!

ann-mj left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants