3계층 아키텍처에서 에러나 로직을 반영하는 기준

3계층 아키텍처 적용

리펙토링은 다 했는데 기존 로직이나 미들웨어를 어디에 어떤 식으로 반영하면 좋을지 알 수 없어서 조금 검색을 해 보았다.

비밀번호 해싱

3계층 아키텍처에서의 비밀번호 해싱은 서비스 계층에서 구현하는 것이 일반적이라고 한다...

비즈니스 로직 계층 (서비스): 애플리케이션의 핵심 비즈니스 로직을 구현하는 계층. 데이터의 유효성 검사, 비즈니스 규칙의 적용, 비밀번호 해싱과 같은 보안 조치 구현 등의 작업이 이루어진다!

왜 서비스 계층에서 이루어질까?
1. 캡슐화와 재사용성: 서비스 계층에서 구현함으로써, 비밀번호 처리 로직을 다른 부분의 애플리케이션에서 재사용할 수 있게 됨. 이는 코드의 중복을 줄이고, 유지보수성을 향상시킨다.
2. 보안: 비밀번호 해싱과 같은 보안 관련 로직을 비즈니스 로직 계층에서 처리함으로써, 데이터가 저장소에 저장되기 전에 적절한 보안 조치가 적용되도록 한다... 이래서 레포지토리 단계가 아니라 서비스 단계에서 이루어진다고 함.
3. 분리 원칙: 프레젠테이션 계층(컨트롤러)은 사용자의 요청을 처리하고 응답을 관리하는 역할에 집중한다. 보안 로직이나 비즈니스 규칙의 구현을 서비스 계층에 위임함으로써 책임의 분리를 명확히 함.

따라서, 회원가입 기능을 구현할 때 비밀번호 해싱은 데이터가 최종적으로 저장소에 저장되기 전, 즉 서비스 계층에서 처리하는 것이 가장 적절함!!!

---

로그인 시 쿠키를 생성하는 로직이나 쿠키 검증하는 로직

애플리케이션의 보안 요구사항과 구조에 따라 달라질 수 있지만 일반적으로는 컨트롤러와 서비스 계층 사이에서 이루어진다고 한당...

단계별 처리

1. 프레젠테이션 계층(컨트롤러): 사용자 인증 후 쿠키를 생성하고 클라이언트에 전송하는 로직은 주로 프레젠테이션 계층에서 처리한다. 이는 HTTP 요청과 응답에 직접적으로 관련된 작업이기 때문이다!!
   쿠키를 생성하고 설정하는 작업은 사용자의 인증 과정이 성공적으로 완료된 후, 사용자에게 특정 세션을 식별할 수 있는 정보(예: 세션 ID)를 제공하기 위해 필요한 것... 그리고 클라이언트로부터 전송받은 쿠키의 유효성을 검증하는 초기 단계 역시 프레젠테이션 계층에서 수행될 수 있다.
2. 서비스 계층: 쿠키에 포함된 정보(예: 세션 ID, 토큰 등)의 실제 검증 로직은 서비스 계층에서 처리하는 것이 적절하당...
   예를 들어, 쿠키에 포함된 토큰을 이용해 사용자 세션의 유효성을 확인하거나, 토큰에 포함된 사용자 권한을 검증하는 과정은 비즈니스 로직의 일부로 간주된다고 한다. 이러한 처리는 데이터의 보안과 관련된 중요한 비즈니스 규칙을 포함하기 때문에 서비스 계층에서 수행되는 것이다... 🙄

결론적으로, 로그인 시 쿠키 생성 및 클라이언트에 전송하는 작업은 프레젠테이션 계층(컨트롤러)에서 처리하는 것이 일반적이며, 쿠키 내용의 심층 검증 및 관련 비즈니스 로직 처리는 서비스 계층에서 수행하는 것이 적절하다.