[%] 계층간 의존관계를 너무 엄격하게 하니 DTO가 너무 많아져

[던전마스터2(yessexnolife)]

Presentation 계층에서 request DTO로 받고

거기서 필요한 데이터만 뽑아다 비즈니스 로직에 맞는 DTO로 변환해서 Application 계층에 던지고

Application 계층에서 지지고 볶은 다음 Domain 계층의 도메인 클래스로 매핑해서 Persistence 계층에 던지고

그걸 JPA 엔티티로 변환해서 repository에 던지고

X발

[익명(106.101)]

눈을 떴구나 러스트갤로 오거라 - dc App

[던전마스터2(yessexnolife)]

[익명(106.101)]

@던전마스터2 dto vo 백날 쓸바에는 파이썬 쓴다 ㄹㅇㅋㅋ - dc App

[익명(211.235)]

엔티티, vo 잘못쓰고 있을 확률 99퍼

[던전마스터2(yessexnolife)]

Persistence 계층의 JPA 엔티티와 별개로 Domain 계층에 기본이 되는 도메인 클래스가 있고, Application 계층은 Domain 계층에 의존해서 도메인 클래스를 다루면서 인터페이스를 통해 Persistence 계층의 crudservice와 느슨하게 결합되어 있고...

[던전마스터2(yessexnolife)]

이 상황에서 Presentation 계층의 request DTO를 Application 계층에 전달하려면 Application 계층에 request DTO와 도메인 클래스 사이를 잇는 별개의 DTO를 만들거나, Presentation 계층에서 Domain 계층에 의전해야 하는 상황

[익명(211.235)]

Jpa 엔티티랑 도메인 엔티티 매퍼 정도랑 애플리케이션 레이어 dto 정도 있을텐데 그럼 뭐가 많은거지? Dto는 유즈케이스 팔때만 손보면 되는건데

[던전마스터2(yessexnolife)]

request DTO를 Presentation 계층으로 옮겨 버러니 문제가 생겨남. 이러면 Presentation, Application, Domain 세 계층 모두 자기네 DTO를 가지게 되는데 이래도 되는 건가...싶어서

[던전마스터2(yessexnolife)]

아니면 도로 Application 계층으로 request DTO를 보내면 의존 관계 문제는 해결되긴 하는데 씁...

[익명(kimkm2121)]

웹따리는 엔터티랑 리퀘스트만 구분해도 충분 - dc App

[익명(124.55)]

GraphQL을 맛보거라

[익명(222.113)]

jooq나 써라 ㅋㅋ

[익명(121.1)]

눈을떳구나 Map<String, Object>를 쓰거라

[익명(182.213)]

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

[익명(182.213)]

나 궁금한게 자바는 DTO 를 전부 다 정의해줘야함? (몰라서그럼) 예를들어 ts 는 유틸리티 타입으로 돌려쓸수 있잖아