[Refactor] 프로젝트 구조 변경 및 서비스 코드 수정 #14

uijin31 · 2024-12-09T15:12:07Z

🔗 관련 이슈

Resolves #13

👩🏻‍💻 구현 내용

디렉토리 구조를 도메인별 → 계층별로 변경
각 Repository 별로 하나의 Service가 제어권을 가지도록 변경
자잘한 리팩토링 (메서드명 수정, 도메인에 검증 코드 추가 등)
도메인 모델 유닛 테스트 추가 작성

💬 코멘트

[Feat] 예약 현황 조회 / 예약 하기 기능 구현 #12 에서 변경된 부분만 보이도록 base를 feat/#8-develop-booking으로 설정했는데, base를 main으로 하고 [Feat] 예약 현황 조회 / 예약 하기 기능 구현 #12 를 볼 필요없이 이 PR만 보면 되도록 하는게 나을까요??
디렉토리 구조를 변경하면서.. 생각한 아키텍처는 다음과 같습니다!

…Service로 이동

- 이미 예약된 슬롯을 예약할 경우, 예외 메시지 수정

f-lab-lyan · 2024-12-10T01:45:47Z

nowait-api/src/main/java/com/nowait/application/BookingService.java

@@ -45,11 +43,11 @@ public DailyBookingStatusRes getDailyBookingStatus(Long placeId, LocalDate date)
    @Transactional
    public BookingRes book(Long loginId, Long placeId, LocalDate date, LocalTime time,
        Integer partySize) {
-        validateUserExist(loginId, "존재하지 않는 사용자의 요청입니다.");
-        validatePlaceExist(placeId, "존재하지 않는 식당입니다.");
+        userService.validateUserExist(loginId, "존재하지 않는 사용자의 요청입니다.");


이름이 validateUserExist이니까, errorMessage도 userService가 가지고 있는 것이 더 바람직하지 않을까요? :-)

loginId를 확인하는 것이면, "존재하지 않는 사용자의 요청입니다"가 필요하고, 다른 서비스에서 사용자를 조회할 때는 "존재하지 않는 예약자입니다" 이런식으로 사용하는 입장에서 다른 에러 메시지를 전달해주고 싶을 것 같다고 생각해서 errorMessage도 매개변수에 포함 시켰습니다!
차라리 메서드를 오버로딩 해서 필요할 때만 errorMessage를 추가하도록 하는 것이 나을까요? 아니면 에러 메시지를 구체적으로 내려주지 말고 하나로 통일하는 것이 나을까요..🤔 아니면 혹시 메서드명이 잘못된 것일까요?😅

아, 이해했습니다. 이런 경우라면, vlidateUserExist를 boolean으로 하고, 그걸 받아서 에러를 내보내는 로직을 BookingService에 넣는 것이 더 좋을 것 같다는 생각이 드네요. 😎

c22a745 반영했습니다:)

f-lab-lyan · 2024-12-10T01:46:11Z

nowait-api/src/main/java/com/nowait/application/BookingService.java

-        validateUserExist(loginId, "존재하지 않는 사용자의 요청입니다.");
-        validatePlaceExist(placeId, "존재하지 않는 식당입니다.");
+        userService.validateUserExist(loginId, "존재하지 않는 사용자의 요청입니다.");
+        placeService.validatePlaceExist(placeId, "존재하지 않는 식당입니다.");


same as the above

f-lab-lyan · 2024-12-10T01:47:51Z

nowait-api/src/main/java/com/nowait/controller/api/PaymentApi.java

+    public ApiResult<PayDepositRes> payDeposit(
+        @RequestBody @Valid PayDepositReq request
+    ) {
+        // TODO: 예약금 결제 비즈니스 로직 호출


f-lab-lyan · 2024-12-10T01:52:12Z

nowait-api/src/main/java/com/nowait/domain/model/booking/Booking.java

        );
    }
+
+    private static void validateUserId(Long userId) {
+        if (isNull(userId)) {


https://docs.oracle.com/javase/10/docs/api/java/util/Objects.html#requireNonNull(T)

헉 이런 메서드가..! 반영했습니다:) d6e8029

f-lab-lyan · 2024-12-10T01:53:32Z

nowait-api/src/main/java/com/nowait/domain/model/booking/BookingSlot.java

-            throw new IllegalArgumentException("이미 예약된 테이블입니다.");
-        }
-
+    public void book() {


서비스에서 bookingSlot.setBooked(true);라고 부르는 것과는 어떤 차이가 있는걸까요?

setter보다 비즈니스 의미를 더 잘 전달하고 있는 것 같습니다!
현재는 예약을 취소하는 로직이 필요하지 않은데요(물론 추후 추가가 되겠지만..) setter를 쓰면 불필요하게 많은 권한(옵션)을 service에게 제공하는 느낌이라 지양하는 편입니다..!

그런데 반대로는 어차피 book()을 부르면, 똑같은 작업을 할 수 있으니, 권한을 부여하는 측면에서는 같은거 아닐까요? :-) 오히려 비지니스가 BookingSlot에 숨는 느낌이 들어서 ...

dd5906a 반영했습니다:)

멘토님 말씀듣고 고민이 되는 것이.. 전 지금까지 객체지향, DDD를 공부하면서 'setter()는 캡슐화를 위반하는 것이다.', '비즈니스 로직을 도메인 내부로 캡슐화를 하고, 서비스 레이어에는 작업의 플로우가 한 눈에 들어오도록 하는 것이 좋다'와 같이 생각을 했었는데, 저번에 멘토님과 대화 나눈대로 사실 웹 API라는 것이 객체지향을 100% 만족시키지 못하기도 하고.. 실무에서도 이론적인 부분보단 조금 더 실용적인 방향으로 개발을 하는 것 같다라는 생각이 들었습니다! 그래도 여러 채용 공고에서 객체지향 OOP를 언급하기도 하는 걸 보면.. 어떨 때는 또 객체지향을 고려해서 코드를 짜야할 것 같은데.. 언제 어떻게 적절하게 사용을 해야할지 모르겠네요😢
말씀주신 부분에서도 저는 비즈니스 로직이기 때문에 도메인(Booking, BookingSlot)에 넣은 것이었는데, 비즈니스 로직을 서비스단으로 꺼내서 처리를 하는 것이 더 적합할까요?

f-lab-lyan · 2024-12-10T02:00:15Z

nowait-api/src/test/java/com/nowait/domain/model/booking/BookingUnitTest.java

+        try (MockedStatic<BookingStatus> mockedStatic = mockStatic(BookingStatus.class)) {
+            // given
+            when(slot.getId()).thenReturn(bookingSlotId);
+            mockedStatic.when(() -> BookingStatus.getStatusAfterBooking(slot))


이 부분도 괜찮은데, slot의 데이터를 적절히 mocking해도 동일한 결과를 얻을 수 있지 않을까요?

맞습니다! 그런데 테스트 코드를 보는 사람의 입장에서 테스트 대상인 Booking 뿐만 아니라 BookingStatus 구현 내용도 이해해야되서 바로 getStatusAfterBooking() 메서드를 모킹하긴 했습니다! 그런데 static 메서드를 모킹하는 것이 코드가 복잡하긴 하더라구요.. slot 데이터를 모킹하는 것이 더 나을까요?

네, 그런 의도라면, static mocking이 괜찮은 것 같습니다. 👍

f-lab-lyan · 2024-12-23T08:58:45Z

nowait-api/src/main/java/com/nowait/domain/model/booking/Booking.java

-            slot.book(),
-            partySize
+            BookingStatus.getStatusAfterBooking(slot),
+            isNull(partySize) ? 1 : partySize


이건 validatePartySize에서 검증이 끝난거 아닐까요?

partySize는 Nullable한 필드여서 Null이면 기본값인 1을 저장합니다!
validatePartySize()에서는 Null이 아닐 때만, 인원 수가 1 이상인지 확인하는 메서드입니다!
사실 컨트롤러 단에서 Null이면 1을 넣어주긴 하는데.. 혹시나(?)하는 마음에 도메인에도 해당 로직을 넣었습니다!

f-lab-lyan

리뷰가 늦었습니다. 🙏 수고하셨습니다. 👍

commit: c22a745

commit: d6e8029

commit: dd5906a

f-lab-lyan · 2024-12-27T09:57:02Z

nowait-api/src/test/java/com/nowait/application/PlaceServiceUnitTest.java

+            boolean exist = placeService.existsById(placeId);
+
+            // then
+            assertThat(exist).isTrue();


Suggested change

assertThat(exist).isTrue();

assertTrue(exist);

uijin31 added 16 commits December 9, 2024 16:07

structure: 디렉토리 구조 변경 (도메인별 → 계층별)

5f749ca

refactor: UserRepository, PlaceRepository에 대한 제어권을 UserService, Place…

857b4b0

…Service로 이동

test: 서비스 분리에 따른 테스트 코드 변경 및 PlaceService, UserService 단위 테스트 작성

056faaa

test: BookingServiceTest → BookingServiceUnitTest 클래스명 변경

9b35295

test: verify() 메서드를 통해 메서드 호출 검증 추가

4d29db6

structure: 컨트롤러와 애플리케이션 사이의 Response DTO 위치를 애플리케이션으로 변경

2fee9d9

refactor: 생성자 파라미터 순서 변경

b926940

feat: Booking 생성자 파라미터 검증 추가

b0a14e8

feat: 예약 후 상태 반환 메서드를 BookingSlot에서 BookingStatus로 변경

e3576c3

feat: 예약 인원 정보가 없는 경우 1인을 기본값으로 하도록 변경

20e8bfd

refactor: 필드를 직접 참조하지 않고, 메서드를 호출하도록 변경

178c452

- 이미 예약된 슬롯을 예약할 경우, 예외 메시지 수정

refactor: 오타 수정 (결재 → 결제)

0086566

refactor: 메서드명 변경(getStatusAfterBook → getStatusAfterBooking)

5f6b1e2

test: BookingSlot 예약 기능 단위 테스트 작성

00658a0

test: BookingStatus.getStatusAfterBooking 메서드 단위 테스트 작성

04a781b

test: Booking 생성 단위 테스트 작성

dc3ba58

uijin31 added the 🛠 refactor This issue or pull request already exists label Dec 9, 2024

uijin31 requested a review from f-lab-lyan December 9, 2024 15:12

uijin31 self-assigned this Dec 9, 2024

uijin31 changed the title ~~Refactor/#13 refactor booking~~ 프로젝트 구조 변경 및 서비스 코드 수정 Dec 9, 2024

uijin31 changed the title ~~프로젝트 구조 변경 및 서비스 코드 수정~~ [Refactor] 프로젝트 구조 변경 및 서비스 코드 수정 Dec 9, 2024

f-lab-lyan reviewed Dec 10, 2024

View reviewed changes

uijin31 changed the base branch from feat/#8-develop-booking to main December 10, 2024 06:35

refactor: if 대신 requireNonNull() 메서드 적용

d6e8029

f-lab-lyan reviewed Dec 23, 2024

View reviewed changes

f-lab-lyan approved these changes Dec 23, 2024

View reviewed changes

uijin31 added 7 commits December 26, 2024 14:28

refactor: 리소스가 없는 경우 예외 처리 로직을 각 비즈니스에서 해결하도록 변경

c22a745

refactor: 매직 넘버 제거 (default party size: 1)

bdf04f1

feat: book() → setBooked() 변경

dd5906a

test: 서비스 코드 변경에 따른 테스트 코드 변경

165a746

commit: c22a745

style: 스네이크 케이스를 카멜 케이스로 변경

3064e73

test: 도메인 코드 변경에 따른 테스트 코드 변경

df6f8ee

commit: d6e8029

test: 도메인 코드 변경에 따른 테스트 코드 변경

3b08999

commit: dd5906a

uijin31 added the ✌🏻 리뷰 반영 완료 label Dec 26, 2024

f-lab-lyan reviewed Dec 27, 2024

View reviewed changes

f-lab-lyan approved these changes Dec 27, 2024

View reviewed changes

chore: merge main

a0642b5

uijin31 merged commit 8653ae7 into main Dec 30, 2024
1 check passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Refactor] 프로젝트 구조 변경 및 서비스 코드 수정 #14

[Refactor] 프로젝트 구조 변경 및 서비스 코드 수정 #14

uijin31 commented Dec 9, 2024

f-lab-lyan Dec 10, 2024

uijin31 Dec 10, 2024 •

edited

Loading

f-lab-lyan Dec 23, 2024

uijin31 Dec 26, 2024

f-lab-lyan Dec 10, 2024

f-lab-lyan Dec 10, 2024

f-lab-lyan Dec 10, 2024

uijin31 Dec 10, 2024 •

edited

Loading

f-lab-lyan Dec 10, 2024

uijin31 Dec 10, 2024

f-lab-lyan Dec 23, 2024

uijin31 Dec 26, 2024 •

edited

Loading

f-lab-lyan Dec 10, 2024

uijin31 Dec 10, 2024 •

edited

Loading

f-lab-lyan Dec 23, 2024

f-lab-lyan Dec 23, 2024

uijin31 Dec 26, 2024

f-lab-lyan left a comment

f-lab-lyan Dec 27, 2024

[Refactor] 프로젝트 구조 변경 및 서비스 코드 수정 #14

[Refactor] 프로젝트 구조 변경 및 서비스 코드 수정 #14

Conversation

uijin31 commented Dec 9, 2024

🔗 관련 이슈

👩🏻‍💻 구현 내용

💬 코멘트

Choose a reason for hiding this comment

uijin31 Dec 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

uijin31 Dec 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

uijin31 Dec 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

uijin31 Dec 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

f-lab-lyan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

uijin31 Dec 10, 2024 •

edited

Loading

uijin31 Dec 10, 2024 •

edited

Loading

uijin31 Dec 26, 2024 •

edited

Loading

uijin31 Dec 10, 2024 •

edited

Loading