The documentation goes over this scenario via constructor, but clearly
states that all data must be provided before-hand. What about handing
the aggregate root an instance of the repository and letting it do
it's own bootstrapping? This could lead to some interesting lazy
loading scenarios for complex domains. Thoughts?
Hi Chad,
that’s abolutely correct. You can wire any (transient) dependencies in your aggregates. I have taken a similar approach once where an aggregate contained so much information it was impractical to load that all in-memory. Downside is that the persisted part of the aggregate wasn’t event-sourced anymore (otherwise you would rebuild a persistent database each time you load the aggregate).
Sometime, I might come across as a purist. But my rule #1 is that rules should either help, or be broken. ;-).
One thing comes to mind. The constructor is invoked by the framework, using the command as parameter. So you really don’t have any time in between to do the bootstrapping. You can only do that after construction is complete (unless you do some static-based lookup in your constructor). So what I have said will hold valid for state changing operations, but not the constructor operation.
Cheers,
Allard
Oh, an in Axon 2.0 there is a solution for this problem 
You’ll have much more flexibility in the parameters you can use. You can even define your own "ParameterResolver"s. They would allow you to “inject” any type of parameter you wish.