FP와 ddd로 개발 할 때 굳이 dto와 entity를 따로 분리할 필요가 있을까?
dto에서 entity로 변환해서 실제 도메인 영역을 거쳐서 어플리케이션 영역에서 사용하는데, 어차피 fp에서 모든 객체는 read only로 처리하기 때문에 바로 dto를 가져다 써도 되지않을까???
이게 ddd 룰 상에 위반이 되나?
FP와 ddd로 개발 할 때 굳이 dto와 entity를 따로 분리할 필요가 있을까?
dto에서 entity로 변환해서 실제 도메인 영역을 거쳐서 어플리케이션 영역에서 사용하는데, 어차피 fp에서 모든 객체는 read only로 처리하기 때문에 바로 dto를 가져다 써도 되지않을까???
이게 ddd 룰 상에 위반이 되나?
값의 변화가 문제가 되는게 아니라 타입 자체가 바뀔때 도메인 로직이 영향을 받지 말라고 레이어링 하는거지 - dc App
보통 1:1로 맵핑이 되는데 타입이 왜 바껴. 기껐해야 vo를 통한 데이터 검증 정도야 하겠지만, db 혹은 웹에서 파싱된 dto 데이터는 윗 영역에서 그대로 쓸 수 있자나.
그거 속단임 바뀌는 가능성을 열어두고 방어적으로 짜야함 - dc App
애초에 dto에 의존하게 짜면 컨트롤러를 통해서만 동작하게 되는거잖음 외부 입출력과는 별개로 님 로직을 온전히 표현할 수 있어야함 - dc App
당장 테스트만 해도 dto 만들어서 던져야하잖음 - dc App
DDD말고 레이어드 아키텍처로 봐야함 - dc App
레이어드나 DDD나 SOLID나 다들 말하는 계층은 비슷하네.
이건 DDD 이전에 SOLID부터 깨짐 - dc App
어디서 깨진다는건지...
도메인이 DTO(인프라)를 직접 보니까 dip가 깨짐 - dc App
미안 인프라가 아니라 유저 인터페이스 도메인 바깥에 있는거라 의미는 비슷함 - dc App
프레젠테이션영역에서 인프라쪽을 보면 모를까 도메인에서 인프라쪽은 당연히 직접 보는거 아님?
도메인에선 인터페이스만 보고 구현은 다형성으로 의존역전 걸어서 넣으면 안봐도 되잖음 - dc App
인터페이스 레이어 말고 진짜 타입 인터페이스 - dc App
타입 인터페이스는 뭐임?
자바나 타입스크립트에 있는 interface - dc App
아 그냥 인터페이스를 말하는거구나. 굳이 계층구조도 아닌데 인터페이스 쓸 이유가 있나? 물론 엔티티 자체를 구성하는 뼈대를 위해서라면 모를까. 각기 다른 데이터들을 엔티티라는 인터페이스로 통일시키는것 처럼. 하지만 내부 데이터들은 당연히 다 다르겠지만
계층을 표현하려는게 아니라 구현을 도메인에서 분리하기 위한 준비임 - dc App
의존 역전을 걸려면 일단 다형성을 걸어야하니까 안터페이스가 필요함 - dc App
내부 데이터나 상태가 중요한게 아니라 인터페이스로 약속하는 메서드가 중요함 - dc App
아하 이해했다. 결국 entity 만으로도 해결 가능하다는 말이자나.
ㅇㅇ 가능한 엔터티 선에서 다 끝내야됨 - dc App
ㅇㅋ. 도움 많이됐음. 땡큐!
해당 댓글은 삭제되었습니다.
리드온리가 아닌 이유는 뭐임?
그건 개발자가 정하는건데 글에서 fp라고 했으니까 읽기전용이라 해도 될듯 - dc App
객체가 복잡하면 왜 배꼽이 커진다는거임 - dc App
논재랑은 전혀 별개긴한데 그 주장의 근거가 궁금함 - dc App
서로 얘기한 불변의 기준이 달랐던거였네 내가 생각한건 님이 말한 리드온리에 가까운듯 레이지 + diff + 캐싱 이런걸로 비비면 된다고 하려했음 - dc App