I have a (young) system with aggregates that sometimes reference a collection of other aggregates. In such cases I just store a list of guids. When an aggregate emits events, I am emitting something like this
appointmentScheduled
-
apptid: guid
-
date: datetime
-
startTime: datetime
-
endTime: datetime
-
trainerId: guid
-
clients: [guids]
My front end is react/redux, which if you’ve used you’ll find that in your redux store you end up normalizing stuff. So I’ll have trainers in my store, clients in my store and appointments in my store. when I want a view that uses data from all three I just select from all three collections and create the view.
However, I wonder if I will wish I had more data in my events down the line. Will I find that just having guids makes writing reports more difficult, or consuming the data for analysis more difficult down the path? The alternative would be to emit something like the following
appointmentScheduled
-
apptid: guid
-
date: datetime
-
startTime: datetime
-
endTime: datetime
-
trainerId: guid
-
trainerFirstName: string
-
trainerLastName: string
-
clients: [{firstName: string, lastName:string Id:guid}]
The downside to this is that I’ll have to decorate my commands with more data so it can get to the AR and be emitted as events, which means I’ll need to pass more data down from the app to the api, etc. The data is not necessary for the business logic of the AR. I guess all that’s not a big deal but it requires that everything be one way or the other at least on a case by case basis, and ideally for all cases.
Any thoughts?
thanks,
r