0

I've made some small research about Domain Events, and have found few different solutions

  • Udi Dahan solution, which handle events immediately
  • Deferred domain events, which fire off in infrastructure mostly
  • Domain Events which return result

Questions:

  • Which one is a pure Domain Events ?
  • Is it possible to have them all in the same project ?
  • In that case how should I name and distinguish them ?
  • Where to register EventHandler ? Someone mentioned that Application Service is appropriated place, but here I've seen that it was registered right into the Domain Model, and handled there, as well, and not in separate Event handler class.

One more extra question.

For example: When order is created and paid it has to get status "OrderPaid".

Because purchasing and ordering are two different contexts, right after Order was created we need to rise a Domain Event, which should be handled by Event Handler in Purchasing bounded context, but in result of Event Handling, there should be raised one more Domain Event - OrderPaid, which might be handled by Order context again. With monolith application it seems that one solution might be: pass Order object into Event Handlers to achieve expected behavior. Is there any other ways how to solve it, in such architecture style ?

user1016265
  • 2,307
  • 3
  • 32
  • 49

1 Answers1

1

Domain Events were invented to provide a more encapsulated domain model. There's no pure implementation as such, just different implementations with different trade-offs. You can have your events in the same project and there is plenty of guidance in the naming of events in the articles you've referenced.

If you wish to handle long running processes that are eventually consistent between different bounded contexts, I'd probably look into using a shared message bus like NServiceBus or MassTransit.

Adrian Thompson Phillips
  • 6,893
  • 6
  • 38
  • 69
  • Thanks for your reply, but how you would solve the case from example above ? would you solve it with DomainEvents ? with help which one of implementation ? – user1016265 Apr 01 '16 at 08:29
  • It's hard to say without knowing a lot more. From what you've posted I don't think I would choose to use Domain Events (maybe except for the triggering of emails to the customer). I'm unclear about what is going on in the purchasing part of the domain, but if the two bounded contexts need to communicate and the purchasing context is "down stream" of the order context, I'd probably control the tracking of an order in the order context, using some long running process or Saga and then use a message bus or web services to communicate between the two domains. – Adrian Thompson Phillips Apr 01 '16 at 08:58
  • why not ? it's a business event, this is what Domain Events has to be used for, isn't it?. To simplify in purchasing context the order just has to be paid via payment gateway. And don't forget it's a Monolithic application, should I use some extra web mediator there ? – user1016265 Apr 01 '16 at 09:30
  • I understood from your original question that ordering and purchasing are two different bounded contexts. If purchasing is really just some client code for a payment gateway then it can be added as a separate project or component off to one side, referenced by the application layer and although it wouldn't be part of your core domain, it would be within the same bounded context as your ordering. In this case it's much easier to deal with and wouldn't need inter-bounded context communication. – Adrian Thompson Phillips Apr 01 '16 at 09:55
  • In that case, it makes it easier to raise domain events within your domain, so there would be no technical hurdles to you raising an `OrderRaised` or `InvoicePaid` event (note the past tense). – Adrian Thompson Phillips Apr 01 '16 at 09:57
  • Well, event handler (for InvoicePaid event, for instance) has to change status or something else in Order Entity, how that might be implemented ? except passing order object back and forth... – user1016265 Apr 01 '16 at 12:46
  • and if Payment is bad example, what about Offers ? let's say Order and Offers, they are two different contexts. And at some point Offer context has to find all suitable offers and apply them (means reduce order total amount in some particular case) – user1016265 Apr 01 '16 at 12:49
  • *Orders*, *checkout* and *offers* sound to me like different parts of a single *ecommerce* domain or bounded context. I'm not sure you've understood the topic of *bounded contexts* in DDD. It might be best, as this question is just getting broader, if you ask a new question that covers only a single topic. – Adrian Thompson Phillips Apr 01 '16 at 14:04
  • Even though it's a parts from the same domain communication between them still might be solved via Domain Events isn't it ? And question is a purely technical. – user1016265 Apr 03 '16 at 03:23