[design-patterns] 내 도메인 엔터티를 프레젠테이션 레이어에서 분리해야하는 이유는 무엇입니까?

나는 이것으로 나 자신을 고투했다. 프레젠테이션에서 DTO를 사용하는 것이 합당한 경우가 있습니다. 시스템에서 회사 드롭 다운을 표시하고 값을 바인딩 할 회사 ID가 필요하다고 가정 해 보겠습니다.

구독에 대한 참조가 있거나 다른 정보를 알고있는 CompanyObject를로드하는 대신 이름과 ID와 함께 DTO를 다시 보낼 수 있습니다. 이것은 IMHO를 잘 사용합니다.

이제 다른 예를 들어 보겠습니다. 견적을 나타내는 개체가 있습니다.이 견적은 노동력, 장비 등으로 구성 될 수 있습니다. 사용자가 정의한 많은 계산을 통해 이러한 모든 항목을 가져와 합계 할 수 있습니다 (각 견적은 유형에 따라 다를 수 있음). 계산). 이 객체를 두 번 모델링해야하는 이유는 무엇입니까? 내 UI가 계산을 열거하고 표시하도록 할 수없는 이유는 무엇입니까?

나는 일반적으로 DTO를 사용하여 내 UI에서 내 도메인 레이어를 격리하지 않습니다. 제어 할 수없는 경계에서 도메인 계층을 분리하는 데 사용합니다. 누군가가 자신의 비즈니스 객체에 탐색 정보를 넣을 것이라는 생각은 말도 안되며 비즈니스 객체를 오염시키지 마십시오.

누군가가 자신의 비즈니스 객체에 유효성 검사를 할 것이라는 생각? 저는 이것이 좋은 것이라고 말합니다. UI는 비즈니스 객체의 유효성을 검사 할 책임이 없어야합니다. 비즈니스 계층 은 자체 검증을 수행 해야 합니다.

왜 busienss 객체에 UI 생성 코드를 넣을까요? 제 경우에는 UI와 별도로 UI 코드를 생성하는 별도의 개체가 있습니다. 내 비즈니스 개체를 Xml로 렌더링하는 별도의 개체가 있습니다. 이러한 유형의 오염을 방지하기 위해 레이어를 분리해야한다는 생각은 저에게 너무 낯설습니다. 왜 비즈니스 개체에 HTML 생성 코드를 넣을까요?

편집
조금 더 생각해 보면 UI 정보가 도메인 레이어에 속할 수있는 경우가 있습니다. 그리고 이것은 도메인 레이어라고 부르는 것을 흐리게 할 수 있지만 UI 모양과 느낌과 기능적 워크 플로 모두 매우 다른 동작을 가진 멀티 테넌트 애플리케이션에서 작업했습니다. 다양한 요인에 따라. 이 경우 테넌트와 그 구성을 나타내는 도메인 모델이 있습니다. 그들의 구성에는 UI 정보가 포함되었습니다 (예 : 일반 필드에 대한 레이블).

개체를 지속 가능하도록 디자인해야한다면 개체도 복제해야합니까? 이제 새 필드를 추가하려는 경우 두 위치에 추가 할 수 있습니다. 아마도 이것은 DDD를 사용하는 경우 다른 질문을 제기 할 수 있습니다. 모든 영구 엔티티 도메인 객체입니까? 나는 내 예에서 그들이 있었다는 것을 압니다.