usecase 사용 기준
21
작성한 질문수 3
4:56초 쯤 서비스에 어떤 기준에 따라 나누신 컴포넌트를 순차적으로 호출하고 있는데요.
저는 이것과 거의 같은 이유로 usecase를 두고 있었습니다. 하지만, usecase 사용은 목적에 맞지 않거나 과도한 것이고 서비스만 두는 것이 좋을까요?
답변 2
1
안녕하세요 질문 감사드립니다!
저는 개인적으로 usecase를 빠르게 사용하는 것을 선호하지 않습니다!
대부분의 경우 과한 경우가 많다고 생각하고 각 개념 서비스 단위가 성숙해진다면 그것을 조합할 때 usecase를 쓸까에 대한 고민을 하는 편입니다
추가적으로 이것도 많이 개인적이지만 usecase라는 네이밍 자체를 선호하진 않습니다!
이유는 너무 특정 아키텍처에 기인하여 맹목적이고 관습적인 네이밍이라고 생각하기 때문입니다
그렇지만 모든 경우가 그렇지는 않을 것 이기 때문에 적절히 잘 판단해서 쓰면 된다고 생각합니다
모쪼록 답이 되었길 바랍니다! 감사합니다!
0
안녕하세요, 인프런 AI 인턴입니다.
나무늘보님께서 말씀하신 것처럼, usecase를 정의하는 것은 때때로 서비스 계층에 비해 과도하게 복잡할 수 있습니다. usecase를 별도로 정의하는 이유는 주로 특정한 비즈니스 로직을 캡슐화하여 코드의 가독성을 높이고, 테스트를 용이하게 하기 위한 것입니다. 그러나 프로젝트의 복잡도나 규모에 따라 반드시 usecase 계층이 필요한 것은 아닙니다.
서비스 계층만으로 충분히 비즈니스 로직을 처리할 수 있고 팀이나 프로젝트에서 코드의 이해 및 관리에 큰 문제가 없다면, usecase 없이 단순하게 설계를 유지하는 것도 좋습니다. 중요한 것은 코드의 목적에 맞게 각 계층이 잘 정의되고, 유지보수하기 쉬운 구조를 만드는 것입니다.
더 구체적인 가이드라인이 필요하다면 Spring Boot의 How-to 가이드를 참조하거나, 커뮤니티 사이트(예: stackoverflow)를 통해 다양한 의견을 들어보는 것도 좋은 방법입니다.
도움이 되셨길 바랍니다!
궁금한점이 여러개 생겼습니다.
1
50
1
다양한 관점의 코드 경험을 위해 개선하지 않은 코드
1
57
1
histories() 응답에 PointHistory.id를 포함한 이유가 궁금합니다/
1
49
2
SettlementTargetRepository Jquery 질문
1
48
2
부가 기능을 이벤트 핸들러로 분리하는 기준이 있을까요?
1
64
2
엔티티의 pk 를 0으로 초기화하시는 이유가 있을까요??
1
69
2
제미니님 안녕하세요!
1
78
2
개념 간 격벽 분리와 목록 조회 시 발생하는 참조 구조
1
86
2
프로덕트와 프로덕트카테고리 사이의 삭제 정책
1
78
2
새로 개발한다면 구현 순서
1
137
1
의존 방향에 대한 고민
1
128
2
어드민(Back-office)에서 예약 변경 시, '할인 조건 재검증(쿠폰 회수)' vs '기존 혜택 유지' 중 어떤 정책이 일반적인가요?
1
100
2
OrderKeyGenerator 인스턴스화 generate() 질문
1
87
1
외부 API 통합 시 데이터 제어 범위 설계 질문
1
100
1
PG 결제 승인 로직
1
132
2
QnA에서 Join 필드 표현법
1
93
1
결제서비스 콜백 동시성문제 가능성
1
111
2
굿
1
112
1
도메인/엔티티 분리 상황에서 쓰기 작업 하는 방법
1
138
2
도메인 객체와 엔티티 객체 사용
1
139
2
CouponService 의존성 의문
1
100
2
상품 목록 조회 고도화 질문
1
114
2
표현 계층에서의 접근 지점이 다양해지는것과 이를 해결하기 위한 파사드의 도입에 대해 제미니님의 생각이 궁금합니다.
1
124
2
제품상세 코드 느끼기
1
145
2