[클린 아키텍처] 20장 업무규칙 / 엔티티 객체를 가리키는 참조를 요청/응답 데이터 구조에 포함하지말자!

JPA를 처음 사용했을 때 컨트롤러의 ResponseBody 응답 모델에 엔티티를 포함하는 멍청이바보똥깨짓을 한적이 있었..다..ㅎ.ㅎ..

연관관계가 있는 엔티티여서 순환참조가 계속 일어났고... 그렇게 사용하면 안된다는 것을 알게 되었다
(현존하는 JPA 최고 존엄 김영한 강사님 강의에도 나옴)

클린 아키텍처에도 엔티티와 관련한 내용이 나와서 기록으로 남겨본다

엔티티

컴퓨터 시스템 내부의 객체
핵심 업무 데이터를 기반으로 동작하는 일련의 조그만 핵심 업무 규칙을 구체화
엔티티 객체는 핵심 업무 데이터를 직접 포함하거나 핵심 업무 데이터에 매우 쉽게 접근
엔티티의 인터페이스는 핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙을 구현한 함수들로 구성
=> 핵심 업무 규칙!!

요청/응답 모델

입력 데이터 -> 출력 데이터
요청/응답 모델이 독립적이지 않다면, 그 모델에 의존하는 유스케이스도 결국 해당 모델이 수반하는 의존성에 간접적으로 결합됨
엔티티와 요청/응답 모델은 상당히 많은 데이터를 공유
BUT! 두 객체의 목적이 완전히 다름
=> 시간이 지나면 두 객체는 완전히 다른 이유로 변경될 것이고, 따라서 두 객체를 어떤 식으로든 함께 묶는 행위는 공통 폐쇄 원칙과 단일 책임 원칙을 위배
[참고]
단일 책임 원칙(SRP)과 공통 폐쇄 원칙(CCP)에 따르면 동일한 이유로 동일한 시점에 변경되는 정책은 함께 묶인다

엔티티와 요청 및 응답 모델은 목적이 다르므로 각각 만들어주자!

해당 장에 유스케이스에 대한 내용도 있으므로 더 상세한 내용을 알고 싶으시면 20장 업무규칙을 보시길 추천 :)