[AWebOfBrown]

> Could you explain which aspects specifically require a lot of boilerplate code?

Probably the most frustrating part for me is tackling domain events and the implementation of the aggregate root. How have you tackled broadcasting domain events when an aggregate changes in a way that might be of interest to other bounded contexts?

[alex-lawrence]

Without Event Sourcing, I would say there is almost no boilerplate code for aggregates themselves or their root Entities. After all, an Entity can be implemented as plain old class or object. For event-sourced aggregates, it depends on the implementation style. With OOP, there might the typical AggregateRoot base class. With a more functional style, there can even be less of boilerplate code.

About the Domain Event publishing, I'm afraid I don't understand the question. What challenges did you face? Is it about event-sourced aggregates?

[AWebOfBrown]

If you have an aggregate root, it is responsible for knowing when changes to the aggregate have occurred, and thus making those visible.

What is the mechanism for it to do so? Does the aggregate root retain the events and decide when to dispatch them (likely after successful persistence to a datastore)?

Once ready for dispatch, what do you use to handle the events? Some kind of DomainEvents class ala https://udidahan.com/2009/06/14/domain-events-salvation/ ?

This is the boilerplate I'm referring to.