개체 대 집계 대 집계

Question

나는 도메인 개체를 식별하는 데 어려움을 겪고 있습니다.

문제 :

• 회사가 하나 또는 여러 개의 사이트를 가지고
• 사이트는 따라서 주와 여러 연락처
• 을 가지고, 회사가 하나 이상의 연락처가 있어요. 이러한 연락처는 사이트 도구에 할당됩니다.
• 연락처는 회사 사이트하지에 추가해야합니다

내 이해 :

public class Company : IEntity 
    { 
     public int CompanyId {get;} 
     public string CompanyName {get;} 
     //..... 
    } 

    public class Site : IEntity 
    { 
     public int SiteId {get;} 
     public string SiteName {get;} 
     //..... 
    } 

    public class Contact : IEntity 
    { 
     public int ContactId {get;} 
     public string SurName {get;} 
     public bool MainSiteContact {get;}//Confused!! May be this is not the right place 
     //..... 
    } 

    public class SiteContact : IAggregate 
    { 
     public Site ASite { get; } 
     public List<Contact> Contacts { get; } 
     public Contact MainContact {get;}//Confused!! 
     //..... 
     public Contact AddSiteContact(...) 
     { 
     } 
    } 

    public class CompanySites : IAggregateRoot 
    { 
     public Company ACompany { get; } 
     public List<Site> Sites { get; } 
     public List<SiteContact> Contacts { get; } 
     //..... 
    } 

내가 올바른 방향으로 건가요? 만약 내가 잘못

업데이트 는 @Aydin ADN의 대답은 아래의 코멘트 섹션에서 제대로 질문을 정교 @Beachwalker ... 제발 올바른.

@Aydin ADN 나는 그의 질문에 하나 개 이상의 측면을 가지고 있다고 생각 : 이러한 개체는 도메인 기반 디자인 (DDD) aproach의 맥락에서 제대로 맞게 자신의 DDD 프리젠 테이션, 예를 들어, 무엇을 얼마나 1 AggregateRoot, 엔티티, ValueObject 등 2. 도메인 의 해석이 올 바릅니다. (도메인 모델)

Answer 1

첫 번째 : https://www.infoq.com/minibooks/domain-driven-design-quickly - DDD 및 유비쿼터스 언어 챕터는 3 회 읽습니다.

엔티티 모델링 방법에 대한 답은 소프트웨어를 개발중인 비즈니스 시스템의 이해를 기반으로합니다. 이것은 DDD의 중요한 부분 중 하나입니다 - 모델링은 이해 후 발생합니다. 도메인 구동 설계가 아닙니다 데이터베이스 구동 설계.

기존의 데이터 모델링 측면에서 문제를 설명했지만 실제로는 DDD가 아닙니다. 비즈니스 또는 운영 측면에서 문제를 설명해야합니다.

추가 도메인 지식없이 효과적인 모델을 식별하는 데 도움이되지 않습니다. 그러나 연습으로 나는 비즈니스 관점에 더 초점을 문제 설명을 변경하는거야 :

1. 우리의 회사는
2. 회사가 우리 사이트는
3. 등록 된 사이트를 관리하기 위해 등록 사이트 관리 서비스를 제공해야합니다 우리 회사가 사이트에서 우리의 서비스를 수행 할 수 있도록 권한과 최소한 하나의 연락 지점을 유지해야합니다.
4. 등록 된 사이트는 선호 연락처 인 연락처 1 곳을 보유하게됩니다. 이 연락처는 당사가 등록 된 사이트와 상호 작용할 필요가있을 때 먼저 연락됩니다.

위의 내용은 원래 '문제'와 일치하지만 이제는 비즈니스가 보는 방식과 일치하는 방식으로 표시됩니다. 모델링 프로세스에 중요한 각 포인트에 대한 상황 및 추론이 있습니다.이것으로부터 엔티티를 나타내는 명사 (Company, Site, Contact)를 선택할 수 있습니다. 또한 집합 루트를 제안합니다. 사이트

class Site : IEntity, IAggregate { 
    public SiteKey Key {get} 

    public CompanyKey CompanyKey {get} 
    public ContactKey PrimaryContactKey {get} 
    public IEnumerbale<ContactKey> ContactKeys {get} 

    public string SiteName {get} 

    //--domain logic here 
/.. 
} 

DDD의 멋진 점은 이제 연락처가 어떻게 변경 되었습니까? 사이트를 새로운 회사로 이전 할 수 있습니까? 사이트를 관리하기 위해 사이트의 어떤 속성이 필요합니까? 새로운 사이트는 어떻게 등록됩니까? 필요한 최소 속성은 무엇입니까? 이러한 질문에 대한 대답은 최종 사용자가 처리해야하는 부작용에 시달리는 화면과 규칙을 기술적으로 정확하게 수집 한 CRUD의 단순한 수집보다 훨씬 뛰어난 비즈니스 비즈니스 응용 프로그램이 될 것입니다.

이제 최종 모델이 아니라 DOMAIN 모델임을 알리는 것이 매우 중요합니다. DDD에서 가장 큰 문제는 프로그램 클래스가 데이터베이스 테이블과 일치해야 함을 의미하는 CRUD 기반 사고 방식을 가져 오는 것입니다. 도메인 모델이 데이터베이스 모델과 일치하지 않도록 준비하십시오. 또한 필요에 따라 데이터 저장소에서 '멍청한'목록을 가져 오는 메커니즘을 제공하고 실제 비즈니스 가치가없는 항목/컬렉션에 CRUD 작업을 혼합하는 것을 두려워하지 않아도됩니다.

열린 마음을 지키십시오 - DDD는 소프트웨어 개발에 대한 많은 통찰력을 얻는 훌륭한 패턴이자 게이트웨이입니다.