[Docs] week6 & week7 발표자료 업로드 [Feat] 스프링 시큐리티 & MemberService 테스트코드 작성

contents/concepts/week4/jiyun.md

@@ -28,7 +28,53 @@ Client와 Server 모두 유효성 검사 가능하다.<br>
   - 안정적 유효성 검사 및 DB를 통한 유효성 검사 가능
   - Client의 몫까지 다 할 수 있음 but, 검사할 일이 늘어나는 것이니 속도 처리 속도 느려짐
 
-결과적으로 Client와 Server에 유효성 검사를 적절히 분배해야 한다. <br><br>
+결과적으로 Client와 Server에 유효성 검사를 적절히 분배해야 한다.
+
+---
+
+<br>
+
+그렇다면 Server인 `Spring` 에서 유효성 검사를 어디에서 해야 할까?
+
+![validationSpring](../Img/week4/validationPosition.png)
+
+사용자가 입력한 데이터는 각 계층을 지난다. 계층 간 전송되는 데이터로 DTO 객체를 주로 활용하기 때문에 DTO 객체에 대한 유효성 검사를 수행하는 것이 일반적이다.<br>
+_(유효성 검사는 모든 계층에서 가능하다.)_<br>
+
+- **Controller**
+
+  - 사용자의 입력을 처음 받는 곳
+
+  - 사용자의 요청 데이터에 대한 초기 유효성 검사 수행 가능
+  - 주로 입력 형식이 올바른지 확인하는 데에 중점 (ex. 아이디, 비밀번호, 이메일 형식 확인)
+
+- **Service**
+
+  - 비즈니스 로직 (중복 체크, 인증 처리, 재고 확인..) 을 처리하는 계층
+
+  - 데이터의 유효성뿐만 아니라 비즈니스 규칙에 대한 검증도 수행 가능
+  - 주로 비즈니스 규칙을 반영하는 데에 중점 (유효성 검사를 하고 싶으면 @Validated 이용하기)
+
+- **Repository**
+
+  - DB와의 상호작용을 하는 계층
+
+  - DB 스키마의 제약 조건에 대한 검증 일어남
+  - 유효성 검사 수행은 드묾 (유효성 검사를 하고 싶으면 @Validated 이용하기)
+
+<br>
+
+유효성 검사는 보통 Controller에서 진행한다. 사용자의 입력을 제일 처음 받는 곳이며, 잘못된 데이터가 시스템 깊숙이 들어가는 것을 바로 걸러낼 수 있다.
+<br>
+<br>
+Controller 이외의 계층에서도 검사를 진행할 수 있지만, 각 계층의 주요 책임들이 존재한다. 책임에 집중할 수 있도록 이 전 층에서는 전송 데이터 검사를 적절하게 진행하는 것이 좋다.
+<br>
+<br>
+그렇다고 모든 검사를 Controller에 의존하는 것 또한 바람직하지 않다. (한 계층이 다른 계층을 의존하는 것은 좋지 않음)<br>
+Controller에서 Service로 정상값이 항상 전달된다는 보장이 없다. 상황에 맞는 검사를 진행하자.
+<br>
+<br>
+추가로 계층 간 데이터 전달을 위해 사용되는 `DTO`와 DB와 연결돼 사용하는 `Entity` 또한 마찬가지이다. 계층-계층으로 DTO가 전달돼 Entity에 데이터가 들어갈 텐데, 이때 DTO에 정상 데이터가 담겨있다고 확신할 수 있나? 때문에 DTO와 Entity에도 유효성 검사를 해주는 것이 좋다.
 
 ## :evergreen_tree: @Valid vs @Validated