AggregateRootEntity.Initialize should call BeforeApply&AfterApply

[jruizaranguren]

When re-hidrating we want the same logic to apply than when changing state in aggregate.

[yreynhout]

Could you provide a practical use-case for this? The hooks are there to show how to do deferred validation, not really executing logic. I'm already regretting ever putting them there. Since the implementation of the IAggregateRootEntity interface is under your control as of .174 I see no reason why you could not add it in your local copy. Without knowing the circumstances, I would generally advise against putting logic in there during rehydration.

[jruizaranguren]

Yes, I have added it to my local copy, no problem with that. My use case: I'm modeling a role of my aggregate with an idempotent finite state machine. Using beforeApply allows me to avoid repeating some logic in each Apply method and use a more declarative way to express states change. I'm not changing "apply" purpose, i.e., state change, but doing in it in a "centralized" way for a role of the aggregate.

[yreynhout]

Then that's not what you are looking for. You want a custom Play method. Sure, the end result will be the same if you'd extend the Initialize method, but the purpose of the Before/After would be different from the original intent. Again, I'd advise against this sort of thing, in the interest of ease of applying future changes. But in the end, you're the boss. If it works for you, go for it. As an alternative you might want to use a polymorphic event router since that would achieve the same thing, i.e. centralizing rehydration logic. Just a thought.

[jruizaranguren]

Mmm, I share your concerns. I agree with you, the semantics of BeforeApply don't reflect my purpose. Perhaps a polymorhic event router is not even needed and I could use the same idea of Before/After apply in Play. There would be "Preliminars" and "TheCigarette" before and after Play that can be registered :-) Then I just need a virtual Play. I probably do in the next clean phase.