CODEWITHSUNDEEP
c#aggregatedomain-driven-designdomain-events
Ddd
Ddd

Reputation: 185

(DDD) How to handle multiple events that have the same result

I encountered with one problem in DDD application. For example I have two aggregates: Order and Item.

class Order {
...
public bool IsVerified {get;set;}

// other properties
// does NOT contain Items collection
...
}

class Item {
...

public Item(..., int orderId){

   OrderId = orderId;
...
   AddDomainEvent(new ItemCreatedEvent(this));
}

public int OrderId {get;set;}

// other properties
...
}

When new Item is created, it sends an domain event ItemCreatedEvent. There is a handler ItemCreatedEventHandler that changes Order aggregate state:

class ItemCreatedEventHandler : INotificationHandler<ItemCreatedEvent>
{
    public async Task Handle(ItemCreatedEvent @event)
    {
        var order= await orderRepository.GetByIdAsync(@event.Item.OrderId);
        order.IsVerified = false;
    }
}

The problem is when we create for example 10 Items at once for the same Order (Id = 3), each Item will trigger an ItemCreatedEvent that will be handled 10 times by the ItemCreatedEventHandler but the logic of handler will be the same for each a such event: take the same farm (Id = 3) and update the same field (order.IsVerified = false).

What can you suggest in such DDD situations ? Is it ok to handle multiple events in the example I have given ? Or probably some changes in aggregates are needed ?

Upvotes: 1

Views: 336

Answers (1)

Luca Masera
Luca Masera

Reputation: 732

First of all, given that you are following the DDD, I would think about how complex I would implement such a rule:

When an Item is created, the Order requires to be verified again

Then your could choose to do it:

  1. simple: you add an Item, you fire an event, the handler modifies the Order. Super simple, it runs the same piece of code every time, but it's really simple to follow and it does what you expect.

  2. complicated: you add some delay (how long?), or a kind of cache (how big?), and you fire a complex event when the delay is expired or the cache is full. But then, when you look at the code, you have to look deeply to understand domain.

While the first solution does exactly what the rule says, the second one add something that is written nowhere and it will require some time to understand why it has been implemented like this. Because it is written nowhere what to do with multiple Items. There is no mention about this aspect in the rule above.

Anyway, this sentence

The problem is when we create for example 10 Items at once

makes the things unclear. That is why I've wrote that your model looks strange. What I mean is:

  1. would it be possible to to add X Items (you don't care if they are the same or not)?
  2. would it be possible to add the same Item X times?

My rule above fits both (I wrote it according to what you have coded). But the second question add the possibility to extend (but even make it more complicated...), your domain model with a new entity. You could have something like a RepeatedItem (hence no cache or delays), where you create multiple times the same Item and you fire just a single domain event. But you pay the price of a more complex domain.

The question is: is this design giving a better representation of the domain or is it just polluting it with an useless entity?

Once you know better what you are going to model you could also find if the model needs to be extended or what you have is already enough.

For now, I can say to you that as long as the code respects the rule the best solution is to keep it as simple as possible. There is no mention about what do to with multiple items, hence handle the things in a simple way, as you have already done.

Upvotes: 1

Related Questions