DDD를 사용하여 API를 작성하기 위해 dto와 작업하십시오.

Question

dto (데이터 전송 객체)로 작업하기 시작했으며 API의 시스템 아키텍처를 구축하는 가장 좋은 방법에 대해 의구심이 있습니다.

'B', 'C'및 'D'와 관계가있는 도메인 엔터티 'A'를 상상해보십시오. 모든 "A"가있는 json 목록을 반환하는 서비스 'S'가 있습니다. "BDTO 's", "CDTO 's"및 "DDTO 's"로 채워서 해당 서비스에서 'ADTO'를 만드는 것이 맞습니까? 다른 서비스 "S2"가 있고 특정 세트의 "B"를 반환해야하는 경우 "C2DTO 's", "D2DTO 's"가있는 "B2DTO 's"의 다른 트리를 만들어야합니다. 이것을 올바른 방법일까요?

이 방법을 통해 우리는 거대한 복잡성의 DTO 트리를 각 사용 사례에 대한 특정 DTO와 함께 가질 수 있음을 알았습니다.

는 편집 :

은 내가 조립 부분을 잊어 버렸습니다. 모든 DTO에 대해 다른 어셈블러를 구현해야합니까? 예를 들어 엔티티 A의 경우 두 개의 DTO가 있습니다. 동일한 어셈블러를 사용하거나 A1Assembler 및 A2Assembler를 사용하는 것이 더 좋습니까?

Answer 1

나는 당신이 DTO가 무엇인지 착각했다고 생각합니다. 대략 2 종류의 DTO가 있습니다. 1) 도메인 엔티티가 될 수 있습니다. 그런 다음 ADTO, BDTO 및 CDTO를 반환 할 수 있습니다. 하지만 그 DTO의가 (왜 BDTO에서 할 수있는 다른 B2DTO 것) 당신이 당신의 JSON 여기

{ 
Id: 1 
name: "foobar", 
$type: "A", 
B: [ { 
     name: "b-bar", 
     $type: "B"}] 
CIds: [ 2,23, 42] 
} 

보는 것이 무엇 보면

당신이 개체의 2 종류를 볼 수 상당히 일치 될 수 있습니다, 일부 (B의) 하위 개체로 DTO에 전체로 반환됩니다. 기타 (C와 유사)는 ID별로 처리되며 별도로 쿼리 할 수 ​​있습니다. C 쿼리를 구현하는 S2라면 상관 없어요.

2) CQRS와 같은 아키텍처를 사용하게되면 다른 DTO를 갖게됩니다. (투영 또는 명령)하지만 DTO의 이름 지정에서도이를 볼 수 있습니다. Forexample는 AListOnOverviewPageDTO, AUserEditDetailDTO 등

지금 그들이 매우 다른 쓰임새를 나타내는 예측이기 때문에 다른 DTO의를 가지고 매우 의미가 있습니다. (DDD에서 흔히 볼 수있는 완전한 개체가 아닙니다)

업데이트 다른 DTO가 필요한 이유는 두 가지입니다. 무엇보다도 먼저 각 통화를 개별적으로 최적화 할 수 있습니다. 어쩌면 목록이 더 빨라야하므로 CQRS를 사용하면 데이터에 올바른 색인을 넣어 listDTO가 더 빨리 반환 될 수 있습니다. 그것은 당신이 유스 케이스에 대해 더 쉽게 추론 할 수있게 해줍니다. 각 DTO가 1 usecase/screen을 나타 내기 때문에 (그렇지 않으면 userlistDTO에서 케이스를 얻습니다.이 경우에는이 세 필드 만 채워야합니다.). 또한 API가 정직해야합니다. 결코 이제까지 빈 데이터와 "연령"필드를 반환 없지만 다른 호출이 동일한 사용자를 반환하지만 다른 통화와 실제 나이가 같은 사용자를 반환해야합니다. 백엔드가 부러진 것처럼 보입니다. 전/사용자 /리스트를 호출하고 다른 호출/사용자/1/세부 있었다 그러나 경우 세부 통화가 특정 사용자에 대한 더 많은 필드를 반환하는 경우는

Answer 2

귀하의 DTO는 데이터의 집합을 의미한다 천연 것이다 당신을 당신의 고객이 갖고 싶어. 일반적으로 엔티티를 DTO로 복사해서는 안됩니다. 필드를 가지고 있기 때문에 세상과 공유하고 싶지 않을 수 있습니다. 데이터를 입력 한 사람의 ID로 자동으로 '추적'열을 만들거나 비밀번호 필드가있는 고객 개체가 있다고 가정 해 봅시다. DTO의 일부가되고 싶지는 않습니다. 그래서 AutoMapper 등을 사용할 때 반드시주의해야합니다.

DTO를 디자인 할 때 클라이언트가 해당 끝점에서 구체적으로 무엇을 필요로하는지 생각하십시오. 때로는 DTO가 동일하게 보일 수도 있지만 괜찮습니다. 또한 DTO는 필요한만큼 간단하거나 복잡 할 수 있습니다. 미친 예가 하나 있는데, 아티스트, 노래, 해당 노래의 투표율 및 추가 데이터를 표시하는 페이지를 말하면됩니다.

유스 케이스가이를 정당화하면 모든 것을 DTO에 넣을 수 있습니다. DTO는 데이터를 운반합니다.

예, 서비스는 DTOS (POCO)를 반환해야합니다.

또한 DTO는 명명 규칙입니다. "dto"접미사에 얽매이지 마십시오. 클라이언트에서 오는 '명령'은 DTO이지만,이 경우에는 예를 들어 AddNewCustomerCommand라고 부릅니다.

의미가 있습니까?