도메인 모델이란 무엇입니까? 왜 그것이 닷넷의 데이터 셋보다 선호 되는가?

Question

나는 데이터 셋을 사용하여 과제를 진행하고있다. 이제이 소프트웨어 회사에서 일하기 시작했을 때 사람들은 DTO라는 데이터 전송 객체를 사용하고 있습니다. 도메인 모델은 어디서 제공됩니까? 정말 무엇입니까?

감사

Answer 1

DTO = 데이터 전송 개체는 그대로 들립니다. 시스템 계층간에 데이터를 전송하는 객체입니다. 목적은 종종 요청 및 응답 데이터를 유스 케이스에 맞게 조정하는 것입니다. 예를 들어, 응용 프로그램 계층에서 HR 시스템의 CandidateService를 통해 CV를 요청할 수 있습니다. 응시자 서비스는 WorkExperince, Education, Personal Letter 등의 다른 도메인 엔티티보다 많은 정보를로드합니다. 복잡하고 방대한 응답 객체 그래프를 피하기 위해 클라이언트 (GUI)에 대해 정확히 설계된 DTO 객체를 작성하여 repsponse를 평평하게 만들 수 있습니다. 필요합니다.

DTO에 관해서는 많은 이야기가 있습니다. 하지만 소설을 쓰고 싶지는 않습니다 :) 그러나 DTO는 핵심 모델 인 도메인 모델에 속하지 않습니다. DTO는 특히 DDD에서 웹 서비스 (WCF 등)를 사용하는 경우 클라이언트에 대한 응용 프로그램 서비스 간의 통신 도구로 주로 사용됩니다. 그런 다음 DTO는 도메인의 일부를 웹 서비스 메시지 (직렬화 된 DTO)로 직렬화하는 완벽한 방법입니다.

동료들/동료들에게 DTO로 무엇을하고자했는지 물어볼 수 있기를 바랍니다. DTO에는 몇 가지 단점이 있습니다. 일반적으로 여분의 레이어를 제공하기 때문에 유지 보수 단계에서 더 많은 작업을 수행 할 수 있습니다. ...

(거의 새로운 소설로) 나는 DTO를 사용할 때만 실질적인 이점과 이점이 있습니다. 고객의 요구에 정확하게 부합하는 DTO로 복잡한 응답을 전달할 수 있습니다. 그렇지 않으면 클라이언트는 대개 충분한 정보를 수집하기 위해 다른 서비스 또는 메소드를 호출해야합니다.

Answer 2

는 DTO들 (종종 ORM 통해) 데이터베이스에서 데이터를 전송하고, 프로그램의 상위 계층에 해당 데이터를 사용할 수 있도록하는 역할 만 간단한 데이터 구조 개체이다. DTO를 사용하여 적절한 도메인 모델 계층에 공급하는 경우 구조적으로 유효합니다 (중복 될 수 있음). DTO를 도메인 모델 계층으로 취급하는 경우 (즉, 사용자 인터페이스와 별도의 도메인 논리가없는 경우) DTO를 anemic domain model으로 사용하고 있습니다.이 패턴은 심각한 구조적 안티 패턴입니다.