Un approccio basato su eventi è il modo giusto di pensare a questo problema?

Leggendo la tua domanda e le altre risposte, ho l'impressione che ci sia una certa confusione causata dal fatto che il termine "sistema basato sugli eventi" spesso viene usato in modo diverso dal modo in cui è usato nella tua domanda. Sono abbastanza sicuro del requisito

he must inform the system so that it can generate a report afterwards of how much hours a certain project required.

non significa che il tuo sistema deve generare tale rapporto immediatamente quando un datore di lavoro informa il sistema che smette di lavorare su un determinato progetto. Questo è ciò che il termine sistema basato sugli eventi avrebbe senso, per attivare sequenze di azioni dipendenti da un'altra parte indipendente del sistema, evitando ritardi e polling. Nel tuo caso, tuttavia, la generazione del rapporto è probabilmente avviata in seguito da una persona (ad esempio il project manager), e non dal fatto che un dipendente termina il suo lavoro in un determinato giorno.

Qui, basta loggare tuple (employee, project, time, [start|stop]) da qualche parte sarà sufficiente. Quando hai i tuoi dipendenti e i tuoi progetti in un database relazionale, con le tabelle Employee e Project (e le classi corrispondenti), ciò significa che aggiungi una tabella / classe con quattro colonne / attributi EmployerID, ProjectID, Time, StartStop al sistema. Si potrebbe chiamare questa tabella / classe Event , in effetti, ma per evitare qualsiasi confusione, ti consiglio di scegliere un nome più specifico, forse WorkLog . Quindi, quando si tratta di generare report, si può valutare questa tabella e facilmente

retrieve the relevant events work log entries and compute time spans and sum them up.

Questo dovrebbe già risolvere i tuoi "punti in sospeso". Ad esempio,

finding a way to connect two such events so that we know that one refers to work started and the other referes to the ending of that started work.

è facile - ci dovrebbero essere sempre coppie di WorkLog voci nella tabella per la stessa combinazione (EmployeeID, ProjectID), una con lo stato "Start" e una qualche ora dopo con lo stato "Stop", entrambe su lo stesso giorno. Certo, devi assicurarti di avere una strategia nel tuo sistema per affrontare le situazioni se un dipendente dimentica di registrare il suo inizio o fine del lavoro in un determinato giorno, ma non si tratta di un problema tecnico, dovrai risolvere questo problema indipendente dalla soluzione scelta.

the other approach I thought seemed to bloat the employee class [by...] make the employee class hold a reference to the project the employee is currently working on

Ovviamente no. La soluzione precedente non aggiunge né qualcosa alla classe Employee né alla classe Project.

Direi che è meglio che i dipendenti registrino le ore su un progetto anziché avviare e interrompere gli eventi

Avviare e interrompere gli eventi può diventare problematico quando qualcuno si dimentica di riempirli. O quando qualcuno sta lavorando su più di una cosa alla volta. O se devono tenere conto delle pause.

ad es. Dico che inizio a lavorare sul progetto X alle 9 di questa mattina e finisco alle 17:00 4 giorni dopo.

• Sono 4 * 8 ore o ho lavorato 24 ore al giorno?
• Che cosa succede se quei giorni sono venerdì a lunedì? Ho lavorato durante il fine settimana?
• E le pause pranzo?
• E le pause per il bagno?
• E riguardo all'incontro per il progetto Y?
• Che mi dici della correzione dei bug di emergenza per il progetto Z?

Mi piace l'approccio all'evento.

Gli eventi si adattano agli approcci per l'approvvigionamento di eventi di cui parlano le persone, e talvolta in combinazione con Domain Driven Design (DDD) e / o Command Query Responsibility Separation (CQRS).

Se riduci gli eventi al calcolo delle ore lavorate in quanto sei in grado di correlare gli eventi di inizio / fine - e butta via gli eventi sottostanti non appena sei in grado di farlo - questo perde potenzialmente informazioni commerciali utili contenute negli eventi .

Ad esempio, ripetendo (o analizzando in altro modo) il registro eventi, è possibile determinare quante persone erano presenti nel progetto al massimo, o, per esempio, in media o ad un certo punto nel tempo. I lotti di altre cose possono anche essere calcolati dagli eventi. Ad esempio, chi lavorava insieme nel team. (Alcuni tipi di eventi più diversi e avresti davvero alcuni dati da analizzare.)

È abbastanza semplice riprodurre il registro eventi per calcolare alcune informazioni, come le ore lavorate. Facendo qualche altra parte, come il dipendente stesso o la classe dei dipendenti, calcolare una risposta intermedia sembra un'analisi dei dati controproducente e prematura.

Suggerirei di catturare qualcosa sulla falsariga dei seguenti eventi aziendali (secondo i tuoi requisiti specifici):

1. avviare, interrompere, sospendere, riprendere e completare il progetto
2. assegna la persona al progetto
3. sospendere la persona dal progetto (ad esempio le vacanze);
4. riprendi la persona sul progetto (ad esempio, di ritorno dalle vacanze)
5. prelevato dal progetto (ad esempio, riassegnato a un altro progetto)

(Con questi eventi si può supporre che una persona che è assegnata a un progetto lavori quotidianamente il progetto nei normali giorni di lavoro fino a quando un altro evento la modifica.) Le vacanze non verranno normalmente conteggiate a meno che non si abbiano eventi speciali per il lavoro straordinario. Sì, c'è spazio per errori se gli eventi non vengono catturati, idealmente è automatizzato.)

In sintesi, esiste un approccio chiamato sourcing di eventi che sostiene che gli eventi aziendali vengono acquisiti in un log di sola aggiunta. Questo approccio separa le preoccupazioni e riduce l'accoppiamento di coloro che desiderano calcoli / analisi dei risultati da coloro che raccolgono (più vicino) i risultati.

Senza questa separazione, i collezionisti devono sapere esattamente quali risultati calcolare e mantenere per le altre entità da utilizzare, il che confonde le responsabilità e stringe l'accoppiamento. Ad esempio, nel tuo secondo approccio, un intervallo di tempo sarebbe calcolato e salvato per un uso successivo in quanto il problema originale lo identifica come requisito, mentre gli eventi utilizzati nel derivare l'intervallo sono scartati.

L'approccio di sourcing degli eventi offre anche valore di business nel senso di supportare l'analisi (specialmente in postmortem).

Modifica: eventi riformulati come operazioni commerciali attive come da @ commento di Ewan.