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를 채택하여 사용하고 있는데요. 복잡한 읽기 쿼리의 경우 추상화하여 재사용성을 높이기가 쉽지 않더라구요. 그래서 하나의 레포지토리 메소드가 하나의 서비스에서만 사용되는 경우도 심심치않게 발생하는 것 같습니다. (하나의 쿼리가 하나의 뷰에서만 사용된다고 말씀드리는게 나을수도 있겠네요) 그동안 재사용성을 높이기위해 많은 노력을 해봤지만..서비스 요구사항에 따라 어쩔 수 없는 부분인 것 같기도 합니다. 요약하자면, 읽기 레포지토리에 있는 하나의 메소드가 단 한군데에서만 쓰이는 경우들이 많이 발생하는 것 같은데 이 부분은 피할 수 없는 부분일지 영한님의 생각을 듣고 싶습니다.

CQRS 리포지토리 질문

명확한 답변 감사합니다 :)

인텔리제이 커뮤니티에서 콘솔 색상 입히는 방법

application.yml을 사용하는 경우 아래와 같이 넣으시면 됩니다~ spring: output: ansi: enabled: always

cascade 질문입니다.

답변 정말 감사합니다. 앞으로의 개발인생에 큰 도움이 될 것 같습니다. 남은 강의도 즐겁게 시청할게요 :)

cascade 질문입니다.

영한님 답변 감사합니다 :) 남겨주신 링크의 내용 중 DDD의 Aggregate Root와 어울린다 라는 내용이 있었는데요. 이에 대해서 간략하게 영한님의 생각을 듣고 싶습니다. 예전에 회사에서 Clean architecture를 도입하자는 의견이 나왔고 그에 따라 전사적으로 도입한 경험이 있습니다. 물론 좋은 내용의 패러다임이고 장점/단점이 존재하였는데 스타트업 특성 상 인력 교체가 자주 이루어지기 때문에 Clean architecture의 규칙을 계속 유지하기가 상당히 힘들었던 경험이 있습니다. DDD또한 요즘에는 조금 덜하겠지만 아직도 많은 개발자들에겐 생소한 패턴이라고 생각이 되는데요. 3번 질문 무엇이 좀 더 명시적인가에 대해 영한님 또한 cascase를 사용하지 않는 것이 명시적이다 라고 답변을 주셨는데, 만약 DDD를 도입하여 구현하고 있다고 가정한다면 Cascade 기능을 사용하실건가요? 질문을 간략하게 요약하면, 명시적이지 않은 기능도 특정 패턴 또는 패러다임에 부합할 때는 사용을 해야할까? 에 대한 생각을 듣고 싶습니다!