업무적인 요소 크게 볼 때 statistics, admin 이 있음.

업무적인 요소란 화면단 기준? 으로 보면 될듯
그래서 전자는 통계쪽 서비스 기준을 하나의 업무 도메인으로 본거고
admin 이라는 관리자 서비스도 하나의 업무 도메인으로 본거임

그럼 api 호출할때 이렇게 가는거임
127.0.0.1/statistics/~~
127.0.0.1/admin/~~

즉 백엔드에서 이렇게 콘트롤러 두개가 있어야하는거임.
statisticsContrroller
adminController

그럼 이제 디비를 보면 뭐 이렇게 테이블들이 있다고 하자.
User, Order, Product, Option, History

그러면 UserRepository, OrderRepository...
이런식으로 테이블 1:1 매챙된 레파지토리 객체가 각각 있겠지?

그리고 Controller에서 바로 Repository를 호출해도 뭐 가벼운 서비스면 노상관인데,
비지니스 로직적으로 할게 많거나 뭐 다른곳에 메시지도 보내고 그런게 있을 수도 있으니
Service를 거친다고 가정을 하면 Service도 하나가 더 있어야함.

그러면 UserRepository, UserService가 생김.

여기서 UserRepository에서 뽑은 결과는 User 테이블의 컬럼이니까
UserEntity도 interface로 뭐 미리 만든게 필요함.


그러면 콘트롤러 업무적인 요소가 섞인건 도메인으로 콘트롤러로 아예 나눈거고
테이블과 연관이 큰쪽은 Repository, Entity, Service로 하나로 묶었음.

statisticsContrroller에서 UserService, OrderService
둘다 객체가 있으니 메소드 호출도 가능한거고

adminController에서도 UserService, OrderService 객체 뭐 쓸 필요있으면 쓰는거잖아.

그러면 DTO는 어떻게함?
사실 테이블의 엔티티는 있기는 한데 어떤 조인 특수한 쿼리로 뽑는 결과라고 하면
바로 레파지토리에서 뽑을 때 entity를 rows로 못받잖아

그럼 어떤 그것만의 특수한 뷰모델 entity로 rows를 받아야하는거잖아?
그러면 entity랑 더해서 dto라는걸 이 service에서 쓰는거마다 폴더에 몰아박아서 관리해주는게 맞는거임?

레스트 에이피아이 진짜 진심 개고수 답변좀