Service와 Entity 비즈니스 로직에 관해

그렇군요! (3번 답변은 잠깐 넣어두고 최대한 엔티티에 비즈니스 로직을 모아 응집력을 높이려고 한다고 가정했을 때) 그렇다면 말씀해주신 4번에 따라 infra레이어(레포지토리)를 호출해서 무언가 값을 가져와서 비교해야하는 로직의 경우 비즈니스 로직이라고 하더라도 엔티티가 아닌 서비스레이어에 위치할 수 밖에 없는 경우라고 생각해도 될까요?

Spring Security 관련 질문입니다.

한가지 질문이 더생겨서 작성합니다. 찾아보니 Interceptor라는 기능도 있어서 filter와 둘 중 무엇을 사용할 지 고민이 되네요. 저는 현재 특정 엔드포인트(컨트롤러)마다 별도의 권한을 부여하는 기능이 필요합니다. 그래서 Interceptor만으로도 충분히 구현이 가능할 것으로 생각이 됩니다. 1. 찾아보니 로깅과 같이 전역적으로 처리해야하는 부분은 filter를 사용하고 엔드포인트(컨트롤러) 별로 디테일하게 인증/권한 처리는 interceptor로 한다는 글을 봤는데 위에 말씀드린 제 요구사항에 따르면 interceptor로 구현하는것도 괜찮은 방법이라고 생각합니다. 이 부분에 대해서 영한님의 생각을 듣고 싶습니다. 2. 실무에서는 인증처리와 관련해서 일반적으로 어떤것을 사용하나요? 감사합니다.

DTO를 만드는 레이어에 관한 질문

안녕하세요 영한님. 위 답변을 보고 생각하던 중 질문이 하나 더 생겨서 댓글 남깁니다. 1. " 실용적으로 엔티티를 전체 구조에서 사용하자(물론 아키텍처 방향에 따라서 엔티티 노출은 제약할 수 있다) " 라고 하셨는데, 그렇다면 응답으로 내보낼 DTO는 컨트롤러에서 조합하여 사용하시나요? 2. 찾아보니 https://www.inflearn.com/questions/15292 에서 Modelmapper 관련해서도 답변을 주셨더라구요. 2019년도 글인데, 현재에도 영한님은 DTO를 직접 손으로 매핑해서 사용하고 계시나요? 감사합니다 :)

엔티티에 FK컬럼값 관련 질문입니다.

확실하게 이해했습니다. 감사합니다 :)

CQRS 리포지토리 질문

하나만 더 질문드릴게요. 실무에서는 파이썬을 사용하고 있지만 스프링 구조처럼 Service, Repository까지 나눠둔 Layered architecture를 채택하여 사용하고 있는데요. 복잡한 읽기 쿼리의 경우 추상화하여 재사용성을 높이기가 쉽지 않더라구요. 그래서 하나의 레포지토리 메소드가 하나의 서비스에서만 사용되는 경우도 심심치않게 발생하는 것 같습니다. (하나의 쿼리가 하나의 뷰에서만 사용된다고 말씀드리는게 나을수도 있겠네요) 그동안 재사용성을 높이기위해 많은 노력을 해봤지만..서비스 요구사항에 따라 어쩔 수 없는 부분인 것 같기도 합니다. 요약하자면, 읽기 레포지토리에 있는 하나의 메소드가 단 한군데에서만 쓰이는 경우들이 많이 발생하는 것 같은데 이 부분은 피할 수 없는 부분일지 영한님의 생각을 듣고 싶습니다.