인프런 커뮤니티 질문&답변
작성한 질문수
DB 레이어 잘 다루는 법
해결된 질문
작성
·
45
·
수정됨
2
안녕하세요. DB 레이어를 다루는 것에 대해 몇가지 질문이 있습니다.
프로젝트 버전 1.1
포인트 적립 트랜잭션
리뷰 작성ReviewService.addReview)에서 포인트 적립PointHandler.earn )이 한 트랜잭션에서 이루어져야 될 것 같다고 생각했는데 분리되어 있습니다. 이렇게 처리해도 충분한지 여쭤보고 싶습니다.
CancelService, PaymentService 에서는 같은 트랜잭션에 있음
낙관적 락 예외 처리
PointBalanceEntity 에는 동시성 처리를 위해 @Version(낙관적 락)을 두었다고 해주셨습니다.
현재는 낙관적 락 예외가 발생하면 500 에러가 발생할 것으로 보이는데, 저는 평소 최대한 이 낙관적 락 예외를 잡아서 적절히 다른 예외로 변환하여 던지도록 했었습니다.
낙관적 락 예외에 대해서 500에러가 발생하도록 처리하는 것으로 충분할지 고민됩니다.
Repository, JpaRepository 분리
현재 프로젝트는 서비스 -> 컴포넌트(Finder, Handler, ...) -> JpaRepository 형태로 계층 관계가 있는 것 같습니다.
그런데 재미니님의 유튜브를 보면 서비스 -> 컴포넌트(Finder, Handler, ...) -> Repository(개념 객체를 다루는?) -> JpaRepository 형태의 계층을 이루고 있는 것으로 보입니다.
첫번째 계층구조를 보면 종종 서비스에서 단순히 컴포넌트를 한번 호출하는 정도인 경우가 많은 것 같습니다. 두번째 계층구조를 사용한다면 서비스에서 단순히 컴포넌트를 한번 호출하고, 그 컴포넌트에서도 단순히 Repository를 한번 호출하는 정도인 경우도 많이 생길 것 같습니다.
이러한 이유로 저는 첫번째 계층구조 정도로 충분한가? 라고도 생각했는데 두번째 계층구조를 선택하시게 되는 이유가 궁금합니다.
두번째 계층구조 관련해서 여러 영상들이 있겠지만 우선 저는 아래 영상 참고했습니다.
Repository 가 분리된 경우에서의 검증, 업데이트 로직
데이터를 검증, 업데이트할 때 어떤 재미니님과 같은 프로젝트 구조를 가져간다면 어떤 식으로 코드가 나오게 될 지 궁금합니다.
검증, 업데이트라 하면 제가 생각한 예시 상황은 리뷰가 7주일이 지나면 업데이트 할 수 없다는 요건이 있다고 가정해보겠습니다.
제가 생각한 것은 아래와 같습니다.
public class ReviewService {
private final ReviewFinder reviewFinder;
private final ReviewProcessor reviewProcessor;
public void update(ReviewUpdate reviewUpdate) {
var review reviewFinder.get(reviewUpdate.id());
if (review.canUpdate()) {
throw new CoreException();
}
var updatedReview = review.update(reviewUpdate);
reviewProcessor.update(updatedReview);
}
}이전에 프로젝트 구조에 대해서 고민이 많이 되었을 때 재미니님의 유튜브를 보면서 프로젝트 구조를 잡는데 도움이 많이 되었습니다.
그런데 제가 그 의도나 스타일을 완전히 이해하지는 못하고 있는 것 같아서 재미니님의 스타일들을 한번 배워보고 싶습니다.
유튜브에서부터 정말 도움 많이 받고있습니다. 좋은 강의 감사합니다!!
답변 2
0
안녕하세요 질문 감사드립니다!
포인트 적립 트랜잭션
유사 질문이 있어서 해당 답변 참고 부탁드립니다!
https://inf.run/3z6MS
낙관적락 예외 처리
예외처리는 상황에 따라 전략을 결정하기 나름이라고 봅니다! Advice 레벨에서 정의할 수도 있고, 한번 더 예외를 감쌀수도 있고, 예외를 아예 먹고 에러 로그를 남기고 지나갈 수도 있죠!
상황에 맞춰어서 적절한 구현을 하는게 맞다고 생각합니다!
해당 강의에서는 낙관적락에 대한 부분이 핵심이 아니다보니 Advice 에서 공통 에러로 처리하고, 내부 로그를 통해 추적해서 처리하는 식이라고 이해해주셔도 될 것 같습니다!
이것 또한 요구사항과 고객한테 에러를 얼마나 친절하게 알려줄 것인지에 대한 관점으로 생각해보면 좋다고 봅니다!
Repository, JpaRepository 분리
프로젝트의 구조 자체는 상황을 적절히 잘 봐야합니다! 해당 강의에서 상황 설명을 드렸지만
상당히 소규모 팀이고, 요구사항은 매일 변칙적으로 변하고 좀 더 효율적이고 기민하게 작업 할 수 있는 구조를 채택했다고 봐주시면 될 것 같습니다!
저는 실무에서도 가능한 작고 심플한 구조를 통해서 서비스를 성장시키는 것을 선호합니다
특히 도메인의 진짜 정체에 대해서 잘 모르는 상황에서는 이 구조가 오히려 자유도와 유연함을 통한 이점을 얻기 좋았던 것 같습니다!
쩌스트 예제의 경우는 제가 도메인을 온전히 알고있고, 단독 프로젝트기 때문에 강제성을 더 올리기 위해 해당 구조를 썻었습니다! 😃
Repository 가 분리된 경우에서의 검증, 업데이트 로직
적어주신 코드 자체도 가능한 스타일 이라고 봅니다! 이런 부분이 사실 팀 내 협의가 하나하나 쌓여있어야하는 부분이겠죠 😃
만약 제가 같은 팀이라고 가정하고 해당 코드에 대해 표준을 잡는데 의견을 드린다면
비즈니스 레이어로 정의한 곳에 너무 디테일한 로직의 모습이 나와있는 것 같아서 행위 단위로 도구를 만들어 응집도를 올리면 어떨까요?
라고 말씀드려 볼 것 같습니다
현재 강의 예제 코드도 리뷰 작성 후 7일 후 업데이트 할수 없는 기준으로 작성 되어있어서 참고해보시면 될 것 같습니다!
위의 말씀드렸지만 제 경우는 프로젝트 구조를 1개로 가져가지 않습니다
자주 말하지만 소프트웨어는 살아있는 유기체와 같기 때문에 그에 맞춰서 환경을 조성하고 성장 시켜야한다고 생각합니다 😀
그런 측면에서 결국 아직 개발의 주도권이 사람에게 있기 때문에 우리가 처한 상황, 비즈니스의 흐름, 일의 속도, 팀의 구성원, 팀의 역량 등등을 고려해서 적절한 프로젝트 구조 를 잡는게 중요하다고 생각합니다!
너무 비대하고 구현에 절차가 많고, 도메인을 잘 모르는데 오염이 되기 쉽거나, 오버엔지니어링 하기 쉬운 구조 등등 이런 것들을 언제 쓰는게 좋은지
반대로 어떤 상황에서 가볍고 변경이 쉬운 구조를 가야하는지
결국 일을 잘 돌아가게하고, 우리 소프트웨어가 효율적으로 커갈 수 있는 구조를 잡는게 더 중요한 것 같습니다!
질문이 많아서 제가 모두 다 제대로 답변했는지 모르겠네요! 😅
이해가 안가시거나, 추가 질문 있다면 편하게 주시길 바랍니다! 유튜브 시청도 감사합니다!
모쪼록 답이 되었길 바랍니다! 완강 후 수강평도 기대하겠습니다!
0
안녕하세요, 인프런 AI 인턴입니다. 심플스택님.
질문해 주신 내용은 데이터베이스 레이어와 관련된 여러 가지 중요한 주제를 다루고 있습니다. 이번 질문에서는 트랜잭션 관리, 낙관적 락, 그리고 Repository 계층 설계에 대해 궁금하신 점이 많으신 것 같습니다. 이러한 질문들은 데이터의 일관성과 성능을 보장하려는 노력의 일환으로 많이 논의되는 주제들이므로 잘 짚어보신 것 같아요.
포인트 적립 트랜잭션
포인트 적립과 관련된 트랜잭션의 경우 비즈니스 로직에 따라 트랜잭션을 하나의 단위로 묶는 것이 바람직할 수도 있습니다. 리뷰 작성과 포인트 적립이 하나의 비즈니스 단위로 간주되어 일관성을 보장해야 한다면 하나의 트랜잭션으로 묶는 것이 좋습니다. 반면, 독립적으로 작동하는 것이 문제가 없다고 판단되면, 분리할 경우의 이점(예: 성능)이 있을 수 있습니다. 관련해서 @Transactional에 관한 질문에서 더 깊은 논의를 찾아보실 수 있습니다.
낙관적 락 예외 처리
낙관적 락을 사용하면서 예외를 식별하고 적절한 응답을 반환하는 것은 사용자 경험과 시스템의 안정성 모두에 도움이 됩니다. 500 에러 대신에 사용자에게 적절한 피드백을 제공하는 것이 바람직합니다. 관련하여 낙관적 락과 트랜잭션 관리에 대한 낙관적 락과 관련한 토론을 참고하시기 바랍니다.
Repository 계층 구조
리포지토리 계층 구조를 설계할 때, 서비스 계층에서 사용되는 컴포넌트들은 비즈니스 로직을 명확하게 분리하고 이해하기 쉽게 만들기 위한 전략입니다. 이때 컴포넌트 사이에 중복이 생기지 않도록 구조를 정리하는 것이 중요하며, 이러한 맥락에서 두 번째 구조가 더 나을 수 있습니다. 비즈니스 로직의 계층 관리 사례에서는 이와 관련된 실질적인 사례를 확인하실 수 있습니다.
업데이트 로직
리뷰 업데이트와 같은 비즈니스 로직은 검증 로직을 통해 처리하되, 비즈니스 규칙을 명확하게 분리하는 것이 효율적입니다. 작성하신 예시는 매우 적절해 보이며, 이런 기법을 더욱 발전시키기 위한 관련 논의를 서비스 계층에서 검증 로직 처리에서 찾아보실 수 있습니다.
이 질문들을 통해 더 깊이 있는 답변 및 논의를 보고 싶은 경우, 제시한 링크에서 추가 정보를 확인하실 수 있습니다. 강의에서 배운 내용을 토대로 프로젝트 구조를 명확히 이해하고 구현까지 하신다면 큰 도움이 되실 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.