이렇게 설계를 함
보통 좀 작으면 레포 빼고 바로 서비스 하고
실제로는 좀 더 세밀하게 잡으면
DB->엔터티(모델)->레포->서비스->DTO->컨트롤러->프론트 요렇게 잡고
이게 스프링 부트의 기초 기조고
일반적으로 DB에서 직접 빼는 엔터티를 DB구조와 매핑되는 객체로 보기때문에 오브젝트 단위를 엔터티로 잡음
이 개념이 사실 제일 기초고.
DB는 데이터 저장소와 내가 뭘 하고 싶은가를 적어두는 기초적인 저장소고
엔터티는 이제 프로그래밍을 할때 가장 기초적인 단위로 치환되는거고
레포지토리는 DB 접근을 하는 쿼라니 CRUD
서비스는 이제 이 비즈니스 로직을 어떻게 처리할것인가임
그리고 그걸 전달하는 것이 DTO 즉 외부로 전달하기위한 데이터 구조. 즉 포장하는거고
그리고 그걸 받아서 컨트롤러가 화면에 뿌려주거나 잡고 있거나 하는거
이 멘탈 모델만 명확하면 사실 백엔드는 거의 규칙적으로 구현할게 정해져있지.
동시접속 막아야하고, 유저 인터럽트가 여러번 걸릴 수 있는 긴 트랜잭션으로 비즈니스로직이 동작하는 코드는 보통 어느단계에서 관리함? 이것도 결국 신뢰도 높이려면 관계디비에 task 내용을 record 단위로 추상화해서 쌓아야함?
보통은 task 레코드 쌓아야하지만 기본적으로 task의 조건에 따라서 도메인 객체로해야지 이 경우에는 DDD접근이 맞음. 서비스 안에서는 긴트래잭션으로 접근하면 DB 락을 너무 오래 잡고 있어서 데드락이 자주 걸린다