인프런 커뮤니티 질문&답변
작성한 질문수
구조랑 패턴 관련해서 질문
해결된 질문
작성
·
73
0
현재 실무에서 ORM(Prisma)을 채택해서 백엔드를 만들고 있어요.
ORM으로 할 수록 Repository패턴과 조합이 좋지않다고 생각이 들고 실제 팀리더도 Repository패턴을 같이 쓰는거에 부정적이고 실제로 사용하지 않아요. 그렇다고 service 하나에 몰아 넣으니 저는 코드 읽기가 점점 힘들어지는거 같아요.
대체할만한걸 검색해보니 CQRS패턴이나 Query Object가 나오는데 아니면 서비스파일을 여러개 두거나... 강사님 같은 경우에는 실무에서 어떻게 대처하시는지 궁금합니다.
답변 2
0
안녕하세요! 피치플리님!
service 하나에 몰아 넣는 방식에 어려움을 많이 겪으셨군요!
위에서 말씀주신 CQRS패턴도 좋은 방식으로 많이 사용되고 있어요!
하지만, 조금 더 근본적으로 들어가서 일반적으로 API가 복잡해지는 경우의 많은 부분은, 권한과 상태 그리고 이에 따른 액션이 점점 복잡해 지는 이유가 일반적일 것 같아요!
(예를들면, 비공개상태를 Private 이라고 하였을 때, 이를 조회할 수 있는 가능액션은 user 조회시에는 조회가 안되고, admin 조회시에는 조회가 가능해야된다 등이 예시가 될 수 있을 것 같아요!)
참고할 만한 방법을 소개드리자면,
먼저 첫번째로는, 하나의 서비스에 모든 것을 몰아 넣지 마시고 하나의 역할을 하는 서비스들로 잘게 쪼개신 다음, 서비스들을 조립하는 방식으로 문제를 해결해 보시는게 좋을 것 같아요!
다음 두번째로는, 액션과 상태를 분리하여 enum 타입으로 정의해 두시고,
api 요청을 받은 컨트롤러 또는 리졸버단에서 switch 하여, 권한 및 액션에 따라 일치하는 서비스를 호출해 주시면 복잡도를 낮출 수 있습니다!
(이 과정에서 검증하는 서비스 역시 따로 분리하는 것이 좋습니다.(ex, 글 작성 권한이 있는지, 삭제 가능한 권한이 있는지, 공개 가능한 권한이 있는지 등))
0
안녕하세요, 인프런 AI 인턴입니다.
피치플리님, ORM을 사용할 때 어떤 구조나 패턴을 선택하는지가 중요한 문제인 것 같습니다. ORM과 Repository 패턴이 함께 사용되기 어려운 측면이 있는데, 이는 ORM 자체가 이미 데이터 접근을 추상화하고 있기 때문입니다.
이 상황에서 추천할 수 있는 몇 가지 방법은 다음과 같습니다:
CQRS 패턴: 이 패턴은 읽기와 쓰기 작업을 별도의 모델로 분리하여 관리하는 방식입니다. 데이터 읽기 전용 쿼리와 데이터 수정 명령을 분리하여 코드의 명확성을 높일 수 있습니다.
Query Object: 복잡한 쿼리를 객체로 캡슐화하여 관리하는 방법입니다. 이렇게 하면 각 쿼리에 대한 로직을 분리할 수 있어서 코드의 가독성과 유지보수성이 향상됩니다.
서비스 파일 분리: 서비스 단위를 더 작게 쪼개어 각 서비스가 특정 기능만을 담당하도록 하는 것도 좋은 방법입니다. 이로 인해 코드가 분산되고, 더욱 읽기 쉬운 구조를 가질 수 있습니다.
각 방법은 상황에 따라 장단점이 있으므로 팀과 함께 논의하여 적절한 방안을 선택하는 것이 좋겠습니다. 실무에서 다양한 시도를 통해 가장 적합한 구조를 찾아보세요!
추가적인 자료가 필요하다면 Spring Boot 문서의 ‘코드 구조 만들기’ 부분도 참고하시면 좋을 것 같습니다.