Come si finisce con l'event-sourcing se si utilizza un approccio xDD?

2

Quando lavori in un modo TDD o BDD, i tuoi test di unità dovrebbero guidare il tuo progetto. Ma come si finisce con l'event-sourcing usando una tecnica xDD? Per come la vedo, l'event sourcing è qualcosa che devi adottare subito per trarne il massimo vantaggio.

Diciamo che inizi senza event-sourcing e fai un rilascio. Più tardi, quando rilascerai la versione 2.0, ti renderai conto che sarebbe fantastico usare l'event-sourcing, ma a quel punto hai già perso tutti gli eventi dalla versione 1.0, quindi è molto più difficile da implementare. O prendi qualche tipo di backup del tuo db prima di event-sourcing e usalo come base e poi aggiungi event-sourcing in più?

    
posta Tomas Jansson 28.11.2011 - 09:23
fonte

2 risposte

4

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.

    
risposta data 11.12.2011 - 20:27
fonte
1

Personalmente ritengo che il sourcing di eventi rientri nella categoria degli "stili architettonici" e non sarà mai facile cambiare gli stili a metà progetto. Detto questo è possibile (l'ho fatto io stesso in passato). Ecco una serie di post del blog che iniziano con questo che delinea un possibile approccio .

Sia TDD che BDD sono davvero "requisiti primi" e in genere avrete requisiti sufficienti per avere un'idea di quale sia lo stile architettonico più adatto. Prendere questa decisione in modo errato può essere molto costoso - e senza cadere nella trappola del "grande design in primo piano" - questa decisione è quella su cui vorrete passare un po 'di tempo.

Ad un livello più pratico puoi generare uno o più eventi di inizializzazione dai tuoi dati esistenti.

    
risposta data 28.11.2011 - 10:32
fonte

Leggi altre domande sui tag