✨ [STMT-62] 스터디 생성 기능 구현

[05AM]

🤔 어떤 방식으로 해결했는지 적어주세요

• 스터디 생성하는 기능을 구현하였습니다.

🙋 중점적으로 리뷰 했으면 하는 부분이 있다면 적어주세요

• 구현하다가 어느 상황에 usecase mapper를 사용해야 할지, 그냥 생성자로 생성해야 할지 헷갈리는 부분이 있었습니다.
• 또한 Study를 생성하기 위해서는 Study domain의 id가 필요한 상황에서 study domain을 생성한 후에 생성자에 넣어주어야 했기에 usecase mapper를 사용하지 못했습니다.
• 또한 스터디 생성은 스터디 내부에서 수행하는 기능이라고 생각하고, 비즈니스 로직이 있기에 study 클래스 내부에 create라는 이름의 정적 메서드로 구현했는데, studydomain이나 image url을 받는 것이 조금 어색해보이기도 하고 사실 어떻게 할지 뚜렷한 방향이 보이지 않아 구현은 했지만 개운하지 않은 상태인 것 같습니다. 😅
• 혹시 이에 대해서 의견이 있으시면 중점적으로 리뷰해주시면 감사할 것 같습니다!

추가) 스터디 생성 로직을 한꺼번에 구현하다보니 변경사항이 좀 많은 것 같습니다. 조절하기가 어려웠는데 혹시 이런 경우 테스트 코드와 본 코드를 나눠서 pr을 올리는게 좋을까요?

코드를 어떻게 나눠서 올려야 할지 고민이 됩니다!

[zxcv9203]

• 구현하다가 어느 상황에 usecase mapper를 사용해야 할지, 그냥 생성자로 생성해야 할지 헷갈리는 부분이 있었습니다.
• 또한 Study를 생성하기 위해서는 Study domain의 id가 필요한 상황에서 study domain을 생성한 후에 생성자에 넣어주어야 했기에 usecase mapper를 사용하지 못했습니다.
• 또한 스터디 생성은 스터디 내부에서 수행하는 기능이라고 생각하고, 비즈니스 로직이 있기에 study 클래스 내부에 create라는 이름의 정적 메서드로 구현했는데, studydomain이나 image url을 받는 것이 조금 어색해보이기도 하고 사실 어떻게 할지 뚜렷한 방향이 보이지 않아 구현은 했지만 개운하지 않은 상태인 것 같습니다. 😅
• 혹시 이에 대해서 의견이 있으시면 중점적으로 리뷰해주시면 감사할 것 같습니다!

스터디 생성이 어떠한 값을 받아 스터디를 만들기 위한 어떠한 처리를 하기 위함이라면 괜찮은 것 같습니다.

헷갈리는 부분이 있다면 일단 기준을 정해보시는 것도 좋은 것 같습니다.
현재 어떤 기준으로 매퍼를 사용하고 생성자를 사용했는지에 대해 알려주시면 더 의미 있는 이야기를 할 수 있을듯 합니다,,! 👍

추가) 스터디 생성 로직을 한꺼번에 구현하다보니 변경사항이 좀 많은 것 같습니다. 조절하기가 어려웠는데 혹시 이런 경우 테스트 코드와 본 코드를 나눠서 pr을 올리는게 좋을까요?
코드를 어떻게 나눠서 올려야 할지 고민이 됩니다!

테스트와 본 코드를 나눠서 올리는건 좋지 않다고 생각합니다 (불가피한 상황이 있는 것이 아니라면)
말씀하셨던대로 테스트는 작성한 코드에서 어떤 부분을 생각하고 작성했는지 볼 수 있는 문서화의 요소로도 동작하기 때문에 이를 나눠서 올리면 오히려 코드 이해에 어려움이 생길 수도 있을 듯 합니다.

현재는 하나의 기능을 구현하기 위해 너무 많은 기반 코드를 같이 작성한 것이라고 생각할 수 있을 것 같습니다.
도메인과 같은 내용을 리팩토링한 코드 -> 기능 PR 이런느낌으로 하면 더 PR 단위를 쪼갤 수 있다 생각이 듭니다.

근데 900자 정도면 괜찮습니다 하하 👍

[05AM]

헷갈리는 부분이 있다면 일단 기준을 정해보시는 것도 좋은 것 같습니다.
현재 어떤 기준으로 매퍼를 사용하고 생성자를 사용했는지에 대해 알려주시면 더 의미 있는 이야기를 할 수 있을듯 합니다,,! 👍

클라이언트의 요청 값만 매핑해서 생성 가능하다면 매퍼, 요구사항을 따르는 비즈니스 로직에 따라 값을 넣어줘야한다면 도메인 내부에 구현하는게 맞다고 생각하여 내부에 정적 팩토리 메소드로 구현했습니다.

그런데 study headcount나 meeting schedule의 경우 매핑만 하면 되는 값인데 study 도메인 내부에서 usecase mapper를 사용하는 것은 의존성이 높아진다고 생각하여 그냥 생성자로 생성했습니다.

만약 서비스단에서 해당 클래스들을 매퍼로 만들고 study의 create 메서드에 넣어주는 것도 생각해보았는데 인수가 너무 많아지는 것 같아서

지금 제 생각은 usecase mapper를 활용하고 싶은데 사용하기가 애매한 부분이 있어 그런 것 같습니다

근데 900자 정도면 괜찮습니다 하하 👍

하하 다행입니다 👍👍☺️
리뷰 고생하셨습니다!! 후에 답글 달겠습니다~!

[zxcv9203]

헷갈리는 부분이 있다면 일단 기준을 정해보시는 것도 좋은 것 같습니다.
현재 어떤 기준으로 매퍼를 사용하고 생성자를 사용했는지에 대해 알려주시면 더 의미 있는 이야기를 할 수 있을듯 합니다,,! 👍

클라이언트의 요청 값만 매핑해서 생성 가능하다면 매퍼, 요구사항을 따르는 비즈니스 로직에 따라 값을 넣어줘야한다면 도메인 내부에 구현하는게 맞다고 생각하여 내부에 정적 팩토리 메소드로 구현했습니다.

그런데 study headcount나 meeting schedule의 경우 매핑만 하면 되는 값인데 study 도메인 내부에서 usecase mapper를 사용하는 것은 의존성이 높아진다고 생각하여 그냥 생성자로 생성했습니다.

만약 서비스단에서 해당 클래스들을 매퍼로 만들고 study의 create 메서드에 넣어주는 것도 생각해보았는데 인수가 너무 많아지는 것 같아서

지금 제 생각은 usecase mapper를 활용하고 싶은데 사용하기가 애매한 부분이 있어 그런 것 같습니다

스터디의 UseCase에서 해당 작업을 수행하고 스터디 도메인에게 전달해줄수는 없는건가요? 🤔

[05AM]

꼼꼼한 리뷰 감사합니다! 오늘 내로 반영하겠습니다!

[05AM]

헷갈리는 부분이 있다면 일단 기준을 정해보시는 것도 좋은 것 같습니다.
현재 어떤 기준으로 매퍼를 사용하고 생성자를 사용했는지에 대해 알려주시면 더 의미 있는 이야기를 할 수 있을듯 합니다,,! 👍

클라이언트의 요청 값만 매핑해서 생성 가능하다면 매퍼, 요구사항을 따르는 비즈니스 로직에 따라 값을 넣어줘야한다면 도메인 내부에 구현하는게 맞다고 생각하여 내부에 정적 팩토리 메소드로 구현했습니다.
그런데 study headcount나 meeting schedule의 경우 매핑만 하면 되는 값인데 study 도메인 내부에서 usecase mapper를 사용하는 것은 의존성이 높아진다고 생각하여 그냥 생성자로 생성했습니다.
만약 서비스단에서 해당 클래스들을 매퍼로 만들고 study의 create 메서드에 넣어주는 것도 생각해보았는데 인수가 너무 많아지는 것 같아서
지금 제 생각은 usecase mapper를 활용하고 싶은데 사용하기가 애매한 부분이 있어 그런 것 같습니다

스터디의 UseCase에서 해당 작업을 수행하고 스터디 도메인에게 전달해줄수는 없는건가요? 🤔

제가 이해를 잘 못한 것 같은데 studydomain 등을 usecase에서 생성하고 해당 값을 mapper에 전달해준다는 의미일까요?
생성한 study domain과 main Image url 등을 command와 함께 mapper에 인수로 전달하여 study를 받아오는걸 말씀하시는 걸까요?

[zxcv9203]

그런데 study headcount나 meeting schedule의 경우 매핑만 하면 되는 값인데 study 도메인 내부에서 usecase mapper를 사용하는 것은 > 의존성이 높아진다고 생각하여 그냥 생성자로 생성했습니다.

이 부분입니다. 인수가 많은거는 크게 문제되는 부분은 아니라고 생각하긴 합니다. 너무 인수가 많다면 DTO로 감싸서 해도 좋을 것 같습니다.