Question

Do you use aggregate root (AR) types for event parameters?

For example, the first method works with simple types but the second uses complex types. Why do you prefer the first or the second?

AggregateRoot()
{
    private SomeAR _someAR;

    public void DoSomething(SomeAR someAR)
    {
        // Validation and other similar stuff.
        ApplyEvent(new SomethingHappenedEvent(someAR.StringText));
    }

    public void DoAnything(SomeAR someAR )
    {
        ApplyEvent(new NothingHappenedEvent(this, someAR));
    }

    protected void OnDoSomething(SomethingHappenedEvent e)
    {
        _someAR = ???
    }
}

Answer 1

Do question why you are passing in that entity and/or aggregate. What is it that you are really after from those objects? I’ll tell you, it’s their state or a side-effect free function that produces state you want to put in that event.

Coupling your events to your aggregates/entities is going to be hard on your consumers, especially if messaging is involved. Pretty soon you’ll be sprinkling serialization attributes on your aggregate’s/entity’s state (be it fields or properties). Maybe you’ll start to introduce state to be able to give the event the data it wants upon serialization. Bad idea, because you’re giving your aggregates/entities a responsibility – keeping track of state for purposes other than its own behavior – they shouldn’t have in the first place.

It’s not only the coupling and messaging, it’s also a matter of choice: the freedom to represents things differently on the inside (aggregates/entities) and on the outside (events/commands). Most domain objects on the inside are all about behavior, while on the outside the event/command objects are about carrying state and intent forward.

All that said, there’s nothing wrong with double-dispatching into an object to get to it’s state.