1. Repository Layer
JPA나 QueryDsl로 쌩 DB 로직만 작성하는 곳
피라미터, 리턴 전부 DAO
2. CrudService Layer(가칭)
주로 DTO를 피라미터로 받아서 Mapper로 DAO로 변환 후, repository와 상호작용 하는 계층
주로 여러 Application에서 재사용을 가정한 DB와 관련된 로직을 작성하는 곳
가독성을 위해 좀 커진다 싶으면 CQS 패턴을 사용함
여기까지가 공통 모듈
3. Service Layer
각 Application에서 순수 비지니스 로직을 작성하는 곳
DB와 상호작용 할 땐 CrudService를 주입해서 DTO를 주고 DTO를 리턴 받음
한 Application에서만 사용되고 재사용 여지가 없는 DB 로직은 해당 모듈 안에서 따로 repository를 작성하기도 함
이렇게 하니까 확실히 프로젝트가 커질수록 각 계층의 책임은 명확해지는데 의존성 관계는 점점 뚠뚠해지고 복잡해짐
다른 대안이 있을까요
답은없는데 편한대로 - dc App
dao가 엔티티 말하는거임?
Application layer에서 dto에 의존하는 게 맞냐?거긴 순수한 도메인 모델에만 의존해야 하는거 아님? - dc App
해당 댓글은 삭제되었습니다.
CRUD 과정에서 발생하는 비즈니스 레벨의 규칙을 서비스에 넣음 crud에 넣음? 비슷하게 하는데 생각해보니 난 좀 경계가 흐린듯?
상황에 따라 다를듯? 서비스에서 처리하면서 CRUD 서비스를 여러번 호출하는 게 편하긴 한데 이러면 성능이...
지금 스키마 기본규칙은 공통 로직에 반영하고 아닌 애들은 기본 메소드에 오버라이드 넣어서 처리하는데 으음...