Am I going about this the right way? Or am I maybe over-complicating it or missing something?
Penso che tu abbia un inizio di un progetto; stai prendendo in giro i concetti e le loro relazioni di base e i vincoli sulle relazioni, che è un ottimo inizio.
Per me, quello che mi piace fare è prima di fare qualsiasi dettaglio reale su classi e operazioni (es. quali metodi, dove va la logica del business), mi piace enumerare leggermente i concetti e le relazioni nei termini di business che creano l'onnipresente lingua per un modello di dominio. I concetti che hanno identità di business (ad esempio, biglietto aereo con localizzatore di record, utente con nome utente o ID univoco, ecc.) Probabilmente finiranno per essere radici aggregate. Idealmente, questi concetti e relazioni sono già noti nel business e non è necessario provare a reinventarli come parte del design. (E naturalmente, si verificheranno iterazioni, miglioramenti, refactoring, ecc.)
Quindi, per me personalmente, avendo un buon inizio ai concetti e alle relazioni, mi piace fare il design dell'applicazione dalle estremità verso il centro. Ci penso un po 'come progettare un ponte. Mi piace avere un progetto per gli argini prima, poi il mezzo (l'intervallo). In questa analogia, una fine del terrapieno è l'implementazione della persistenza, dove sto pensando ai concetti di modellazione e anche alle loro relazioni e alcuni dei loro vincoli con SQL usando le tabelle. L'altra estremità è l'interfaccia esposta esternamente, dove sto pensando a un'API REST usando i principi OData.
Quindi disegno le classi, i metodi e le operazioni come un ponte che si estende tra i due argini ora noti. Si noti inoltre che abbiamo molte scelte in merito al design della classe (ad es. Per usare ORM o no, quali classi ottengono i metodi e dove vanno le logiche delle applicazioni e delle applicazioni), poiché le classi nel mezzo sono più vicine all'implementazione interna e più lontane API esposta esternamente.
Penso che vorrà una nozione formale di diversi tipi di Utenti (oltre allo Sviluppatore), come il Portavoce di Business - potrebbero essere quelli che avviano i Progetti.
Il termine evento è abusato nel nostro business, quindi cerco di usarlo solo in un modo ristretto (la mia opinione è che un "evento" è qualcosa che è accaduto, una volta, solo ora o in passato, e gli eventi possono fuoco, essere abbonati, ecc ...). Pertanto, puoi scegliere un nome più specifico all'interno del tuo dominio aziendale per ciò che stai chiamando evento. D'altra parte, probabilmente mi muoverò nella direzione di più generici progetti ricorsivamente composti, quindi i progetti possono comporre / decomporsi in qualsiasi numero di altri progetti. Hai già diversi livelli specifici di composizione: Evento, Progetto, Applicazione, perché non diventare più generico? Tuttavia, la composizione ricorsiva potrebbe non essere sufficiente, potrebbe anche essere necessario tenere traccia delle dipendenze tra i progetti (ad esempio tra progetti secondari peer o progetti indipendenti che non sono composti). Potrei provare a formalizzare la nozione di pianificazione insieme alle nozioni di dipendenza.
For my aggregates, what do I do here? Do I write a "service" class like "TeamProjectService" with methods such as "CreateTeamProject"? Or what?
Ho due commenti qui.
In primo luogo, tenderei a considerare gli elementi elencati in grassetto come radici aggregate poiché probabilmente hanno identità solide esternamente riferibili al di fuori dell'aggregato. Le radici aggregate possono essere correlate ad altre radici aggregate (e per le relazioni NxM modellerei la persistenza per ognuna di quelle con la propria tabella di prima classe). Il modo in cui stai usando il termine aggregato sopra mi fa pensare alle relazioni tra le radici aggregate più delle entità all'interno dell'aggregato.
In secondo luogo, probabilmente farei la creazione di relazioni tramite un'operazione associata a una o entrambe le radici aggregate correlate. Ad esempio, un'entità della squadra potrebbe essere in grado di creare un progetto, oppure la raccolta del progetto potrebbe creare un progetto, anche se richiede un team come parametro.
In questi giorni, mi piace utilizzare OAuth2 (ad es. Windows Live, Facebook, Google+, Twitter, Stackoverflow) per l'autenticazione (eseguo OAuth2 direttamente, ma forse ACS di Azure può contribuire ad estrapolarlo attraverso la varietà di provider OAuth2).
