Invece di pensare a Event Sourcing come a un problema puramente progettuale e tecnico, pensate che abbia invece un chiaro vantaggio aziendale. Ad esempio, se sto utilizzando l'esempio di spedizione di Martin Fowler , potrei avere un motivo commerciale per voler sapere dove una nave era in un dato giorno.
È possibile che tu non abbia ancora questo motivo commerciale. C'è una possibilità che avrà quel motivo, un po 'di tempo in futuro? Alcuni requisiti di business non riguardano solo la funzionalità di cui hai bisogno ora, ma il mantenimento delle opzioni aperte (quasi l'opposto di YAGNI). Puoi consultare il lavoro di Chris Matts su Opzioni reali per scoprire di più.
Ora che hai stabilito il vantaggio aziendale, pensa a TDD e BDD come ad aiutarti a stabilire quali di queste classi sono responsabili di tale vantaggio. TDD e BDD non ti aiutano a scovare un buon design tanto da allontanarti da quelli cattivi. Ti fanno prendere in considerazione la responsabilità di ciascuna delle tue classi, forniscono un esempio di come usarlo garantendo in tal modo codice utilizzabile e assicurano che ogni aspetto della classe sia veramente prezioso. Puoi comunque ottenere questi vantaggi e ottenere anche i tuoi requisiti di architettura.
Piuttosto che cercare di ottenere l'architettura giusta, pensa al costo di sbagliare. Sarebbe davvero difficile adottare l'event-source in un secondo momento? Se hai scoperto che il costo era proibitivo e il business non ne aveva bisogno, quanto sarebbe difficile tornare alla persistenza basata sullo stato? Come Chris ha detto in passato, se non sai quale tecnologia è giusta, non scegliere la tecnologia giusta. Scegli quello che è facile da cambiare. Ha già ragione o avrai più informazioni in seguito che ti aiuteranno a prendere decisioni migliori. Il proprietario del tuo prodotto o esperto di business potrebbe anche aiutarti a decidere se per ora valga la pena pagare un vantaggio aziendale.