Calculations in Aggregate or in Projection?

[Adam Furtenbach]

We are about to build an invoice system for our customer, the system will consume an event sourced participant application.

The invoice system will process events, such as:

* ParticipantStartedCourse

* ParticipantCompletedCourse

* ParticipantAbortedCourse

* ParticipantWasPresent

* ...

Each participant course instance is also attached to a price node with contains a lot of billing rules.

Was thinking of using a couple of aggregates that I pretty much only append new event to as they arrive from the participant system. Doing all the annoying calculations in the projection.

And when the invoice admin locks an invoice, I take a snapshot from the projection and persist it it an invoice aggregate.

Advantages of doing this, would be that. If we later realize something was calculated incorrectly, we could just take a new snapshot the newly calculated invoice projection. And make a differential invoice with all the corrections.

What would be advantages be with doing the calculations in the aggregate instead?

[urbanhusky]

Do you need the calculations to satisfy or check some invariants? If not, you could move it to the read side into the projections.
Locking an invoice should yield events as well. You're talking about a snapshot, are you sure that this isn't a data-centric approach to solving a problem that is actually a process?
Also beware that your projections might only be eventually consistent. Generally, you should not read from your read side in the aggregates.