※ 읽기에 앞서

본 시리즈는 작성자의 이해와 경험을 바탕으로 실습 위주의 설명을 제공하고자 작성되었습니다.
실습 중심의 이해를 목표로 작성되었기 때문에, 다소 과장되거나 생략된 부분이 있을 수 있습니다.
따라서, 이론적으로 미흡한 부분이 있을 수 있는 점에 유의하시고 양해 부탁드립니다.

또한, Spring Boot 기반의 Backend 개발에 중점을 두고 설명하고 있으므로,
Frontend와 관련된 내용은 별도의 참고자료를 검색/활용하실 것을 권장드립니다.

📌 데이터의 흐름

실습에 앞서 데이터의 흐름을 알아야 합니다.

├── domain(model)
├── dto
├── repository
├── service
├── controller

아, 벌써부터 머리가 막 어지럽고 인터넷 창을 닫고싶어집니다.
그러니 여러분을 위해 이게 의미하는 바를 간단히 요약해보겠습니다.

📖 데이터의 흐름

데이터의 흐름은 아래의 순서를 거친다.
DB(domain) -> repository -> service -> dto -> controller
DB(domain) <- repository <- service <- dto <- controller

엄밀히 말하면 domain은 DB가 아니라, 테이블 정의입니다.
편의상 기억하기 좋고 이해를 돕기 위해 저렇게 분류를 해두었습니다.

간단히 정리하면 아래의 핵심만 기억하면 됩니다.

Service 단을 거칠 때, Entity가 Dto로 변환(복사)된다.

또 다시 의문이 생깁니다.

"그래서 Entity는 뭐고 DTO는 뭔데?!"

📖 Entity vs DTO

Entity: 실제 DB에 저장된 데이터 하나 하나를 의미하는 단위
DTO: 실제 데이터인 Entity를 필요한 속성만 뽑아 복사한 데이터

그러니까 정리하면 Service 단을 거칠 때 데이터를 복사하여 전달하겠다는 것입니다.

"왜 번거롭게 DTO로 복사를 하지? 그냥 Entity를 바로 가져다 쓰면 안 돼?!"

개발을 좀 공부해보셨다면 '은행원 알고리즘' 문제를 아실겁니다.
'A가 입금하는 동안, B가 출금하면, 최종잔고에 문제가 생긴다.' 라는 것인데,
물론 Entity로 처리하더라도 은행원 알고리즘이 완벽하면 문제는 없습니다.

하지만, 이런 비슷한 다른 문제가 발생한다면?
실제로 개발을 진행했을 때 이런 문제가 발생하면 오류가 난 상태로 DB에 저장됩니다.

만약 결제 시스템이나 핀테크 기능이었다면 실제로 금전문제가 발생할 수 있고,
법적 소송까지 이어지는 상당히 민감한 문제가 발생할 수 있기 때문에,
'Entity를 복사하는 한 단계'를 더 거쳐 안전성을 확보하겠다는 것입니다.

그 외에도 게시판 목록같은 경우 내용에 관련한 데이터는 필요 없기 때문에
불필요한 데이터는 제거하고 성능을 향상시키기 위한 목적도 있습니다.

주저리 주저리 떠들었습니다만, 간단히 요약하면 아래와 같습니다.

"나는, 제목만 필요하고 내용은 필요없으니까, 커스터마이징할거야!"
"그런데, 혹시 오류가 발생할 수도 있으니까, 복사본을 사용하는거야!"

본 시리즈는 작성자의 이해와 경험을 바탕으로 실습 위주의 설명을 제공하고자 작성되었습니다.
실습 중심의 이해를 목표로 작성되었기 때문에, 다소 과장되거나 생략된 부분이 있을 수 있습니다.
따라서, 이론적으로 미흡한 부분이 있을 수 있는 점에 유의하시고 양해 부탁드립니다.

또한, Spring Boot 기반의 Backend 개발에 중점을 두고 설명하고 있으므로,
Frontend와 관련된 내용은 별도의 참고자료를 검색/활용하실 것을 권장드립니다.