브랜치 : be/dev/refactor_architecture/#1483
LentAdminController + UserAdminController 분리 → Admin 통일하기
Facade
•
FacadeService + QueryService / CommandService는 Interface 만들지 말기
◦
인터페이스를 추가하는 이유는 추상화 + 다형성으로 추후 교체를 용이하게 하기 위함
◦
Service는 내부 로직 뿐이기 때문에 교체되기 보다는 로직 수정 혹은 새로운 메서드 추가가 주된 변화일듯
•
Cabinet, Lent, Search, User, Admin
•
패키지별 Facade 1개씩
•
Controller에 대응되는 호출마다 메서드 1개씩 필요
•
Mapper 사용(DTO 변환)
Service 목적 & 기능
•
QueryService / CommandService 분리 → CQRS 아님, Service에 메서드가 너무 많아서…
•
Service의 메서드 명에는 가급적 비즈니스 측면으로만
•
하나의 Service 메서드는 단일 데이터에 대한 조회, 가공
•
Mapper 사용 X
•
메모리에 추가적인 부하가 생기지 않는다면, 가급적 데이터 정렬은 Repository보다 Service에서
•
Policy는 Service와 동일 계층 느낌 → Facade에서 데이터 조회해놓고 Policy로 정책 검증
◦
Policy에 넘길 때는 가급적 인자로 넘기기 → 인자가 5개 넘어가면 DTO로
◦
Policy 내부에서는 값 조회, 수정, 삭제 X
•
Repository에서 가져온 Optional을 꺼내기 (get vs find 적용)
•
Overloading 적용(ex. getUser(Long userId) + getUser(String username))
Repository
•
API 이름에 Entity 넣지 말기(ex. findUserById → findById)
•
이름은 find ~~ + Optional로 꺼내기
•
Repository 이름은 가급적 뭘 조회해오는지 알 수 있도록(Spring Data JPA와 유사하게)
◦
이름에 비즈니스 로직이 들어가있다면(ex. Active 등) 수정하기