응용 프로그램에서 사용법을 다르게 고려한다면 엔티티의 하위 집합을 만드는 것이 합리적입니까? IE. 나는 엔티티를 가져 와서 첫 번째 엔트리의 속성 중 일부만 가지고 새로운 엔티티를 정의한다. 이제 중복되는 엔티티가 2 개 있지만 다르게 사용되지만 궁극적으로 동일한 데이터 테이블에 유지됩니다. 이 엔티티는 다른 저장소를 통해 액세스 할 수 있습니다.엔티티를 DDD의 작은 엔티티로 분할 하시겠습니까?
나는 DDD에 대해 배우기 시작 했으므로 잘못하면 의견을 말하고 알려주십시오. 내 생각은 다음과 같습니다.
엔티티가 다른 저장소를 통해 액세스되는 경우 엔 고유 한 클래스가 필요합니다. 또한 현재 중복되는 비트가 앞으로 중복되지 않을 수 있으며 공유 기본 클래스를 사용하는 경우 도메인을 더럽힐 가능성이 높습니다.
두 클래스가 별도의 하위 도메인의 일부인 경우 별도로 있어야합니다. 내 생각은 내가 듣고 기억하는 예제의 일부를 기반으로합니다. Rob Connery's interview on Hanselminutes. 제품에는 소비자에게 중요한 몇 가지 특성 (가격 책정, 설명 등)과 창고 담당자에게 중요한 몇 가지 속성 (창고의 위치, 무게, 크기 등)이 있습니다. 그 에피소드에서 내게 암시하는 바는 두 제품이 한 번 정의되고 공유되는 대신 도메인에서 별도로 정의되어야한다는 것입니다.
"응용 프로그램에서의 사용법"을 사용하면 다른 부분을 다른보기로 표시한다는 의미인데, Fowler와 같은 프리젠 테이션 패턴을 그의 Presentation Model에서 사용하는 것이 좋습니다 (또는 WPF 응용 프로그램을 개발할 수 있습니다. Model-View-ViewModel (MVVM)이라는 WPF 전용 버전을 사용하십시오.
"사용법"에 따라 다른 하위 도메인 또는 도메인의 일부에있는 엔티티의 다른 속성을 사용한다는 의미라면 Chris에 동의합니다. 아마도 다른 엔티티로 분리하는 것이 좋습니다. 그 이유는 도메인 모델에서 해당 특정 (하위) 도메인에서 엔티티가 사용되는 방식을 반영해야하기 때문입니다. 그리고 상황에 따라 엔티티의 다른 부분을 사용하는 경우에는 엔티티의 이름 지정에 반영되어야하는 설정에서 다른 의미가있을 수 있습니다. 그리고 그것이 나 였다면 아마 엔티티 각각에 대해 하나의 저장소를 만들 것입니다. 엔티티와 리포지토리간에 1 : 1 매핑을 갖는 것이 대부분의 경우 경험 한 것 같습니다. 그러나 다시. Chris, Rob Conery, DDD를 시도하는 개발자의 90 % 나는 DDD 게임에 상당히 익숙하다. 그래서 나의 경험은 더 경험 많은 누군가에 의해 무효화 될지도 모른다. :)
이것은 나의 성향이었다 – zsharp