Distrubuted domain driven design modeling

Question

I am working on an events ticketing system and I am trying to use DDD. However, I am unsure about how to model some of my aggregates.

I have the main Event aggregate:

public class Event : Entity, IAggregateRoot
{
    public string Name { get; private set; }
    public Organizer Organizer { get; private set; }
    public Venue Venue { get; private set; }
    public DateTime StartsAt { get; private set; }
    public short MinAge { get; private set; }
    public bool IsAvailable { get; private set; }
    public EventType Type { get; private set; }
    //constructor and mehtods
}

and also have the Venue and Organizer Aggregates:

public class Venue : Entity, IAggregateRoot
    {
        public string Street { get; }
        public Venue(Guid id, string street) : base(id)
        {
            Street = street;
        }
    }


    public class Organizer : Entity, IAggregateRoot
    {
        public Organizer(Guid id) : base(id)
        {
        }
    }

My questions are:

I have different services that handle creation and other operations for the Venues and Organizers. The Events service is consuming kafka messages from the other two services and persists the venues and organizers in its own database. I would like to mention that the Venues and Organizers services have a lot more information about their respective entities than the Events service, so it is not a 100% data duplication. Is this the right way to share data between different services?
In the events service, should the Organizer and Venue be considered an aggregate or an entity? Neither of those is accessed on itss own in the context of the Event service.
How should I handle persisting and retrieving entities from the database?

user_18452174 · Answer

An Entity is something that has an own entity, an unique identifier, that has significance. You use an aggregate when you have entities (and also value objects) with a strong dependency and has sense manage all of them like a single object. In this form, outside you work with some entity (the aggregate root) that manage all the aggregates entities.

With an example is easier to understand. Suppose you have Invoice entity and InvoiceLine entity. Both of them are important, has a unique identifier... and you may work with them as entities. You have a table in the database for invoices and for the lines. Working with the entities as is, you must control some things like, for example, the total of the invoice. When in any place you change the price of a line, you need have near the invoice, to update the total. It's a very simple example but in more complex scenaries, this kind of things ends with wrong data because in some place, you forget update some related data.

So, it's interesting have and aggregate root that contains this two aggregates and all about them are encapsulated in the root aggregate. You update line price through the aggregate root and root update the total of the invoice. Each entity have a reference to the root.

Usually, the aggregate root has a repository to manage the data of all their aggregates. Entity Framework differ a bit in this point, having a repository per entity.

Distrubuted domain driven design modeling

1 Answers