1. API 하나에도 단순 CRUD 이상의 비즈니스 규칙이 포함된다
오늘 관리자 API를 설계하면서 API는 단순히 요청을 받고 응답을 주고받는 URL을 만드는걸 떠나 시스템의 흐름과 정책을 표현하는 법이라고 느꼈다
관리자 회원가입은 단순 생성이 아니라 승인대기인 상태로 등록되고 슈퍼 관리자의 승인 이후에만 관리자의 행동할수있는 권한이 생긴다
단순히 크리에이트나 세이브를통해 저장한다는 개념을떠나서 해당기능이 시스템에서 어떤 흐름을 가지게되는지 어떻게 사용하면 더욱더 멋진 코드가 되는지 먼저 생각하는게 중요하다는걸 깨달았다
2.상태값은 enum으로 관리하는 것이 좋다
처음 과제를보고 관리자 상태나 , 역활을 구분할때 enum 클래스를 생각하지못했다 다른 조원들의
코드설계를 어느정도 보고난후에 아 이때 enum클래스를 썼었지 생각하고 enum하나로 관리하는걸
생각했다 enum을 사용하면 상태값을 명확하게 제한할수있고 내가 직접작성하는 잘못된 오타를 줄일
수있다 항상 쉽게 코드작성하는걸 버리고, 새로운걸로 코드짜는 버릇을 들여야할거같다
public enum AdminStatus {
PENDING,
ACTIVE,
REJECTED,
SUSPENDED,
INACTIVE
}3.DTO 가 불필요하게 너무많아도 유지하는게 좋다
관리자 CRUD 를 작업하는중 불필요하게 너무 DTO가 많다는 생각해 튜터님에게 줄이는 방법을 요청했었는데 관리 비용이 증가하더라도 이를 유지해야하는 이유를 설명해줬다. 그래서면 나도 다시한번 찾아보면서 정리하게되었다
1) 보안성 및 안전한 데이터 노출
- 민감 정보 노출 방지: 엔티티(DB 모델)에는 패스워드, 내부 식별자 등 외부에 공개되면 안 되는 민감한 정보가 포함될 수 있습니다. DTO를 사용하면 화면에 필요한 데이터만 골라서 노출할 수 있다
2) 유지보수성과 변경에 유연한 설계 - DB와 화면의 분리 : DTO 와 엔티티 간의 매핑 로직만 수정하면 DB가 변경되어도 컨트롤러 코드를 수정할 필요가없다
3) 성능 및 데이터 전송 효율화 - 불필요한 데이터 최소화 : 대형 엔티티를 그대로 전송하면 불필요한 필드까지 직렬화되어 네트워크 트래픽이 낭비될수있다
4) 명확한 역할 분리 - 클라이언트와 서버간의 데이터전송만을 담당하는 명확한 역활을 지킨다
4.비밀번호 변경은 반드시 현재 비밀번호 검증이 필요하다
비밀번호 변경할때 session 이 있는상태이기때문에 바꾼 비밀번호만 요청 DTO로 가져오면 된다고생각했었는데 평소에 내가 경험했던 UI들을 생각해보면 항상 기존비밀번호를 요청받고, 바꿔야할 비밀번호를 적었던것이 보안관점에서 필요하다는걸 느꼈다
로그인된 사용자라고 해도 세션이 탈취되었을 가능성이 있기 때문에 민감한 작업에서는 한 번 더 본인 확인을 해야 한다
오늘 이 부분을 통해 인증 이후에도 보안 검증이 계속 필요하다는 것을 배웠다
5. 엔티티는 단순 데이터 저장소가 아니라 상태 변경의 주체다
이전에는 Service에서 값을 직접 바꾸는 방식만 생각했다 로직들을 보통 service만 진행하다보니 모든 로직들을 서비스에서만 해결하려는거에 집착을 두고있었다
하지만 오늘 역할 변경, 상태 변경, 승인, 거부, 삭제 기능을 고민하고 찾아보면서 엔티티 내부에 의미 있는 메서드를 두는 것이 더 자연스럽다는 것을 알게 되었다
단순히 값을 변경하는게 아니라 행위 중심의 메서드로 표현하는것이 명확하고 코드의 의도가 잘들어난다는걸 알게 되었다
또한 예외처리같은경우도 객체지향설계를 이유로 서비스에서만 처리하는걸 생각했지만
도메인 객체가 스스로 상태를 변경하도록 설계하는 것이 객체지향 설계의 핵심이라는 것을 다시한번 배우게되었다
