add clock

[DavidBadura]

I think it would be a good idea to add a clock implementation to this library. We can use it to write our tests better and the users can also manipulate the time for their tests. This is the missing part for the "testing" documentation.

[DanielBadura]

I dont think we should do this. The user has already the possibility to replace the method createRecordDate with are "more suitable" one if desired. And manipulating DateTime is always tricky and really painful if done wrong. I think with #58 we already did the job. We dont really need this for our testing usecase, do we?

[DavidBadura]

Yes, you can override it, but it is not good for the dx if the user need to create an own "mock" or "class" to manage clock features. Other event sourcing libraries do it too: https://eventsauce.io/docs/utilities/clock/

[DanielBadura]

Hm, i can see the need for it generally but the solution used by eventsauce is somewhat cleaner from my PoV since it's a different class used for mocking and normal usage. With our solution here it could happen that in production the clock is frozen.

But i cannot provide another solution to this tbh since we cannot inject different classes here in this situation. That's why I'm concered about the consequeces for some dx could be a fatal failure for production. I know, with the eventsauce approach this could also happen, but it seems for me that this is more unlikely.

Maybe a path between would be suitable? Just add the clock class but not directly use it in the AggregateChanged? So the user can add it fairly easily?