Object versus aggregate versus aggregate root

I am trying to identify Domain objects.

Problem:

  • The company has one or more sites.
  • The site has main and several contacts.
  • Thus, the company has one or more contacts. These contacts are assigned to sites.
  • Contacts must be added to Sites not to the company

My understanding:

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; }
        //.....
    }

      

Am I in the right direction? Please correct me if I am wrong ...

An update by @Beachwalker correctly asks the question in the comment section below @ Aydin Adn's answer.

@ Aydin Hell. I think his questions have more than one aspect: 1. How do these objects fit correctly in the context of a Domain Driven Project (DDD) and what is their DDD presentation, for example. AggregateRoot, Entity, ValueObject, etc. 2. Whether the interpretation of the domain is correct. (Domain Model)

+3


source to share


1 answer


First: https://www.infoq.com/minibooks/domain-driven-design-quickly - read what's going on with DDD and Ubiquitous Language sections 3 times.

The answer to how your entities are modeled is based on understanding the business system for which you are developing software. This is one of the important parts of DDD - modeling comes after understanding, it is a Driven Design Domain , not a database driven one.

You described your problem in terms of traditional data modeling, which is good and good, but not really DDD. You need to describe the problem in a business or work environment.

Without additional knowledge of the domain, we cannot help in defining an effective model. However, as an exercise, I'm going to modify the problem description to focus more on a business perspective:

  • Our company provides site management services.
  • Companies register sites for us.
  • Registered sites must have at least one authorized contact person to enable our company to perform our services on the site.
  • Registered sites will have one point of contact, which is the preferred contact. This contact will be contacted first when our company needs to interact with a registered site.


The above matches your original "Problem" but is now presented in such a way that it aligns (my compiled version) as the business sees it. There is context and reasoning for each of the points that are critical to the modeling process. From this, we can single out some nouns that denote entities: company, site, contact. It also offers an aggregate root: Site

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
  / ..
}

      

Now the cool thing about DDD is that we now have more questions: how did the contacts change? Can I move a site to a new company? What properties of the site do we need to manage them? How are new sites registered - what are the minimum properties required? Answering these questions will lead to a significantly higher line-of-business application than a simple CRUD collection, a technically correct collection of screens and rules that are a pain in the ass for end users.

It is now very important to point out here that this is the DOMAIN model and not the final database model (which will end up looking like what you described). The biggest accomplishment for DDD is the shift in CRUD thinking, which implies that the program's classes must match the database tables: be prepared for your domain model to not match your database model. Also, be prepared to provide mechanisms to fetch "dumb" lists from your datastores as needed, and don't be afraid to mix entity / collection CRUD operations with no real business value.

Keep an open mind - DDD is a great reference and gateway to much research in software development.

+7


source







All Articles