dddsample-core | This is the new home of the original DDD Sample app (previously hosted at sfnet) | REST library

Is there any guidance in these situations on the granularity of domain events?

If you are looking for guidance about domain events, event-sourcing is a good search term to use: people who store their domain state in a stream of events spend a lot of time worrying about things like granularity.

Broadly, having multiple domain events associated with a single transaction is common. In other words, you shouldn't hesitate at all to consider multiple domain events when that model is a better fit for your domain than a single event.

A commonly discussed example is a "trade book", where we are matching up buy and sell orders. A single large sell order might close several different buy orders, and it is a natural fit with the language of the domain to be firing different events for each of the orders closed.

In complex processes, it is often useful to be able to back trace the graph of events; C was caused by B was caused by A. The work to perform an analysis may be considerably simpler if we don't have to dig around in B trying to figure out which part of B was the cause of C.

A number of the same motivations for cohesion in our source code also applies to event design.

That said, you normally want domain reasons for multiple domain events, not mechanical reasons. If big, inconvenient to serialize graph of information really is a single atomic change in the language of your domain, then you really should do the work of designing the appropriate schema for it, rather than taking the shortcut of carving the information along arbitrary boundaries so that the data will align with your arbitrary schema conventions.

aka "It depends".