[백재우] sprint3 #149

jaewoo9797 · 2025-02-11T05:37:29Z

안녕하세요 멘토님! 👋

2주차 이후 코드를 보다가 도메인 로직과 비즈니스 로직이 혼합되어 분리가 어려워져 처음부터 다시 코딩했습니다.
어느정도 틀은 잡았지만 다음과 같은 문제가 있었습니다.

파일 관련 코드의 이해 부족 => 제공된 베이스 코드에서는 각 도메인 객체의 id 값으로 파일이름을 생성하여 관리
- id값으로 안찾고, 이메일, 유저 이름, 채널이름 등등으로 객체를 찾으려고할 때는 어떻게 처리해야하는지 이해 부족
- 파일을 관리하는 방법에 대한 이해부족 => 차근차근 해당 기술은 학습하며 진행하겠습니다.
- 2.16 파일 관련 공부 진행 파일관련 공부를 진행한 레포
dto에 파일을 담는방법 => 감이 안잡혔습니다.

최대한 멘토님이 리뷰해주신 내용을 적용하여 의미를 담도록 네이밍하고 복잡하지 않도록 노력하였습니다.

멘토에게

도메인과 비즈니스 로직, 입력과 출력, 요청과 응답을 분리하려고 노력했습니다. 이에 어느정도 이해하였습니다.
패키지 분리에 대해서 생각해보았는데, DDD로 쪼갠 저번과 달리 도메인 패키지를 외부로 빼고, 레포지터리 패키지도 외부로 분리하여 관리하였는데, 부적절한 분리인가요?
분기처리가 필수적일 때 if 문 분기와 삼항연산자로 분기하는 것중 어느것을 더 선호하시나요? (간단한 분기일 경우)
DTO 객체를 엔티티로, 엔티티 객체를 DTO로 변환하는 방법에 대해서 고민하고 있습니다.

질문

예를 들어서 게시글을 저장하는 로직이 존재한다고 가정하겠습니다.
Controller에서는 파라미터로 요청 DTO 객체를 받아서 Service레이어로 넘겨 처리합니다. 그리고 서비스에서는 컨트롤러에서 값을 받아 비즈니스 로직을 수행합니다.

이 때 서비스 레이어서는 DTO의 객체를 알 필요는 없다고 생각하기도하고, 알아도 딱히 문제가 된다고 생각하지 않습니다.
또한, DTO 클래스 안에 객체와의 변환을 담당하는 메서드를 만들어 DTO 역할을 확장하여 서비스 레이어 코드가 간결해지기도 합니다. (개인적으로 DTO에 도메인 객체를 노출시키는 것에 대해선 부자연스럽다고 생각하지만, 서치한 결과와 사람들이 많이 사용하는 방식인 것 같습니다..)

같은 기능을 Converter 객체를 만들어서 toDto, toEntity 등 변환을 담당하는 서비스 객체를 만들어 DTO와 도메인 객체 간의 결합도를 낮추어 활용하는 방법도 있습니다. 이 방법은 도메인이 늘어날 경우 관리해야하는 코드의 수가 늘어나는 단점이 존재하기는 합니다.

다음과 같이 DTO 안에서 변환을 담당하는 것과 converter 객체를 만들어서 변환하는 것에 대해서 멘토님은 어떻게 생각하고 계시는지 궁금합니다. 그리고 컨트롤러에서 DTO 객체를 적절한 엔티티 클래로 변환하여 서비스에서는 파라미터 매개변수에는 일관적으로 DTO 클래스를 받지 않도록 하는 것에 대해서 어떻게 생각하느시는지 알려주세요 😄

// 1. DTO가 변환을 담당한다.
public record ArticleCreateRequest(
        String title,
        String content
) {

    public Article toArticle() {
        return new Article(title, content);
    }
}
// 2, 빈으로 등록한 컨버터가 담당한다.
@Component
public class ArticleConverter {
  public ArticleResponse toDto(Article) {
  }

  public Article toEntity(ArticleResponse articleResponse) {
  }
}

제가 조사해보니 정답은 없는 것 같습니다. 다만 SOLID 원칙과 유지보수성을 고려해서 결정해야 한다는 결론을 내릴 수 있었지만, 경험 부족으로 결정하기 쉽지 않다는 것입니다. 하나의 컨트롤러에서 여러개의 서비스 이용할 경우를 고려하면 서비스 레이어에서는 도메인 객체를 리턴하는게 보다 유연할 것 같기도 합니다.

그리고 현재 코드가 하나의 서비스에서 여러 서비스를 의존하고 있는데, 연관관계가 있는 도메인의 서비스들이 많아질 수록 복잡해질 것 같다고 생각합니다.

콤퍼넌트와 모듈로 서비스를 관리하는 방법에 대해서 알게 되었습니다. 하지만, 충분히 고려하고 사용한다는점과 명세를 잘 해두어야 한다라는 것을 알았습니다.

유저 이름,닉네임, 이메일 비즈니스 로직인 유효성 검증

생각해 볼 부분, 현재 static 으로 정적메서드가 많이 존재하는데, 검증해야하는 부분들이 많아질 경우 어떻게 할 것인가? 장단점 생각해보기 검증하는 로직을 외부 객체로 진행하게 된다면, 장단점 생각해보기

…print-mission into part1-백재우-sprint3

인터페이스 메소드 구현체 구현추가

checkAlready -> throwAlready

kkong101

재우님 과제하시느라 고생하셨어요.!!

kkong101 · 2025-02-19T13:53:48Z

.../main/java/com/sprint/mission/discodeit/application/dto/channel/FoundChannelResponseDto.java

+        UUID channelId,
+        String channelName,
+        LocalDateTime lastMessageTime,
+        Set<UUID> participatedUserId


s 빠졌어요!

kkong101 · 2025-02-19T14:01:05Z

...rc/main/java/com/sprint/mission/discodeit/application/service/channel/JCFChannelService.java

+    public JCFChannelService(
+            ChannelRepository channelRepository,
+            UserService userService,
+            ReadStatusRepository readStatusService,
+            MessageRepository messageRepository
+    ) {
+        this.channelRepository = channelRepository;
+        this.userService = userService;
+        this.readStatusRepository = readStatusService;
+        this.messageRepository = messageRepository;
+    }


@requiredargsconstructor 를 활용해보면 어떨까요 ?

kkong101 · 2025-02-19T14:09:52Z

...rc/main/java/com/sprint/mission/discodeit/application/service/channel/JCFChannelService.java

+
+    @Override
+    public void changeSubject(UUID userId, ChangeChannelSubjectRequestDto requestDto) {
+        User foundUser = userService.findOneByUserIdOrThrow(userId);


아래 자료 한번 참고하면 좋을것 같아요.!

여기에서는 아래같이 사용해도 될듯해요

User user = getUserById(userId);

참고 자료

참조자료 보고 학습해보겠습니다!

kkong101 · 2025-02-19T14:10:04Z

...rc/main/java/com/sprint/mission/discodeit/application/service/channel/JCFChannelService.java

+    @Override
+    public void changeSubject(UUID userId, ChangeChannelSubjectRequestDto requestDto) {
+        User foundUser = userService.findOneByUserIdOrThrow(userId);
+        Channel foundChannel = findOneByChannelIdOrThrow(requestDto.channelId());


여기도 마찬가지입니다.!

kkong101 · 2025-02-19T14:13:15Z

...amp-spring/1-sprint-mission/src/main/java/com/sprint/mission/discodeit/domain/user/User.java

+    public UUID getId() {
+        return id;
+    }
+
+    public Username getUsername() {
+        return username;
+    }
+
+    public Email getEmail() {
+        return email;
+    }
+
+    public String getUsernameValue() {
+        return this.username.getValue();
+    }
+
+    public String getNicknameValue() {
+        return this.nickname.getValue();
+    }
+
+    public String getEmailValue() {
+        return this.email.getValue();
+    }
+
+    public String getPasswordValue() {
+        return this.password.getValue();
+    }


getter 를 활용하여 보일러 코드를 줄여보는건 어떨까요 ?

kkong101 · 2025-02-19T14:15:21Z

...rc/main/java/com/sprint/mission/discodeit/application/service/channel/JCFChannelService.java

+    private void throwIsNotManager(User foundUser, Channel foundChannel) {
+        if (!foundChannel.isManager(foundUser)) {
+            throw new NotChannelManagerException(ErrorCode.CHANNEL_ADMIN_REQUIRED, foundUser.getUsernameValue());
+        }
+    }


throwIfNotManager 가 더 적합해보여요 ㅎㅎ

이렇게 함수 만들어 서비스에서 에러를 던지는게 아니고 호출한쪽에서

channel.throwIfNotManager(user);

이렇게 만들어서 엔티티에서 에러를 던지는것에 대해서는 혹시 어떻게 생각하세요 ?

응집도가 높아지겠군요... 만약 수정한다면, 서비스 메서드 내부에서 함수를 기존 코드처럼 분리하지않고
객체의 메서드를 호출해서 검증할 수 있을 것 같은데요. 메서드 네이밍을 매니저가 아닌것을 확인하는게 메서드의 목적이니까 checkIsManager 로 생각해보았는데 어떤가요..?

kkong101 · 2025-02-19T14:21:58Z

...rc/main/java/com/sprint/mission/discodeit/application/service/channel/JCFChannelService.java

+//        ====> 삼항 연산자와 if 문 분기처리 중 어떤 것을 더 선호해야할까요? 제가 생각하기에는 삼항 연산자가 보기 더 편한것 같습니다.
+//        다음 미션에서는 둘 중 하나 지워두겠습니다.
+//        createChannel = requestDto.visibility() == ChannelVisibility.PUBLIC
+//                ? Channel.ofPublicChannel(requestDto.name(), requestDto.channelType(), foundUser)
+//                : Channel.ofPrivateChannel(foundUser, requestDto.channelType());


지금 상황에서는 if-else 가 더 명시적이며, 나중에 enum 에 값이 추가된다고 했을때도 유리해보여요./

jaewoo9797 and others added 30 commits February 4, 2025 09:23

feat: project migration spring boot

feaa934

feat: 기본 요구사항 구현

f74a943

refactor : user 객체의 필드 리팩토링

425357b

feat: 프로젝트 밀고 다시 설계, 유저의 이름, 닉네임, 이메일 도메인 생성

ff98cb0

유저 이름,닉네임, 이메일 비즈니스 로직인 유효성 검증

docs: change branch for push remote my all branch

004294a

Merge branch 'part1-백재우-sprint3' of https://github.com/jaewoo9797/1-s…

e5df11c

…print-mission into part1-백재우-sprint3

refactor : 불필요한 개행문자 삭제

59261ad

feat: user join feature 구현

cb2ba91

test: user service, repository 로그인 기능 테스트 구현

4c077b0

feat: 유저 비밀번호 암호화 기능 구현

904b252

refactor: In memory user repository 필드 자료구조 변경

8994b9c

feat: 로그인 기능 구현

1abd1ab

fix: test build fail 문제 해결

195cf78

인터페이스 메소드 구현체 구현추가

refactor: method name 변경

297bbd7

checkAlready -> throwAlready

refactor: validate 기능을 도메인 모델 안으로 리팩터링

0db550c

feat: 채널 도메인 구현, 채널 저장, 수정 로직구현

9c38ed3

feat: message 생성 로직 구현

07a68cd

feat: message 수정 삭제 기능 구현

94f27cb

refactor: service 레이어 인터페이스 만들기

2533076

feat: 팩토리 패턴을 이용하여 의존성을 관리

485c7fb

refactor: yaml -> properties

74be0d4

refactor: validator 삭제

5a68077

feat: readStatus 기능 구현

08dd9f0

feat: userstatus 기능 구현

eb5079a

feat: user profile 이미지 관리

c6ad93e

feat: user, channel service 고도화 기능요구 사항 추가

d08f484

feat: channel 조회 기능 구현

f27e819

feat: channel 기능 고도화 구현

f809a24

feat: 추가 요구사항 기능 구현

6a46839

jaewoo9797 added 3 commits February 11, 2025 14:36

refactor: application 파일 확장자 변경

4cf1ba5

refactor: 일관된 코딩 스타일 수정

7cbfa3d

fix: 테스트 실패 오류 수정

cc1d576

jaewoo9797 requested a review from kkong101 February 11, 2025 06:27

jaewoo9797 added the 미완성🛠️ 스프린트 미션 제출일이지만 미완성했습니다. 죄송합니다. label Feb 11, 2025

jaewoo9797 added 6 commits February 11, 2025 16:50

refactor: 중복 함수 묶기 = createChannel 관련 메서드(public, private)

ad5b767

refactor: 분기 처리 삼항연산자, if 문 질문

8fd1599

docs: 요구사항 삭제 (코드에 집중할 수 잇도록)

d023120

refactor: lombok 어노테이션 삭제

fef5055

refactor: 필요없는 데이터베이스 접근 로직 삭제 (ReadStatus)

dfd4968

refactor: 줄바꿈, 잘못된 클래스 이름 수정

bf4d325

kkong101 reviewed Feb 19, 2025

View reviewed changes

kkong101 merged commit 065e943 into codeit-bootcamp-spring:part1-백재우 Feb 19, 2025
1 check passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[백재우] sprint3 #149

[백재우] sprint3 #149

jaewoo9797 commented Feb 11, 2025 •

edited

Loading

kkong101 left a comment

kkong101 Feb 19, 2025

kkong101 Feb 19, 2025

kkong101 Feb 19, 2025

jaewoo9797 Feb 20, 2025

kkong101 Feb 19, 2025

kkong101 Feb 19, 2025

kkong101 Feb 19, 2025

kkong101 Feb 19, 2025

jaewoo9797 Feb 20, 2025

kkong101 Feb 19, 2025

[백재우] sprint3 #149

[백재우] sprint3 #149

Conversation

jaewoo9797 commented Feb 11, 2025 • edited Loading

멘토에게

질문

kkong101 left a 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

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

jaewoo9797 commented Feb 11, 2025 •

edited

Loading