architettura per l'applicazione

Se questa architettura tecnica è la soluzione più semplice possibile per risolvere il tuo problema aziendale, allora è fantastico, non l'hai sovradimensionato. Ma la tua descrizione non è sufficiente per capire se questo è il caso.

Prima di tutto, quali sono i miei criteri personali se l'architettura è ok? In altre parole, quali sono le caratteristiche che dovrebbero avere i miei servizi?

• Prima di tutto, è un accoppiamento basso. Non voglio che tutto il mio sistema si arresti in modo anomalo a causa di un servizio non disponibile.
• Voglio che i miei servizi siano estremamente coesi. Se avessi bisogno di un po 'di funzionalità, voglio farlo in un unico posto.
• Non voglio che il mio servizio sia loquace. Quindi voglio che abbiano una granularità corretta.
• Voglio che siano autonomi, quindi comunicano principalmente tramite eventi e hanno dati decentralizzati.

Per fare ciò è necessario identificare prima la propria architettura aziendale. In altre parole, è necessario identificare le parti logiche del sistema, il loro modo di comprendere e il modo in cui comunicano tra loro. Uso la tecnica chiamata Mappatura delle capacità aziendali . Si riduce a quanto segue:

• Identifica le tue capacità di business di livello superiore. Pensa a quali passaggi il tuo sistema dovrebbe seguire per raggiungere i suoi obiettivi.
• Esamina più a fondo all'interno di ciascun servizio.
• Accanto a due punti precedenti pensiamo al modo in cui i servizi dovrebbero comunicare.

Ciò che mi aiuta è immaginare come funzionava un sistema, o avrebbe funzionato un centinaio di anni fa. Le parti logiche di base rimangono le stesse, i percorsi di comunicazione di base sono entrambi.

Questa è l'attività principale, quella da cui iniziare. Le altre cose come mongo, database di grafici e simili vanno dopo.

Ecco un esempio di un approccio I delineato.

Did I over-engineer or not?

Dipende, in un certo senso, da cosa intendiamo con over-engineering.

Stai visualizzando 3-4 diverse tecnologie di archiviazione, SQL, Graph, MongoDB e Resource Manager. È difficile sapere se questo è o non è eccessivo senza approfondire gli altri aspetti dell'architettura, ma fa una domanda.

Tuttavia, ci sono altri aspetti dell'ingegneria, come la raccolta dei requisiti, i casi d'uso, le specifiche non funzionali (ad esempio, i requisiti di rendimento al carico previsto), l'architettura concettuale, ecc.

Potresti prendere in considerazione l'utilizzo di una metodologia o di una struttura di progettazione nell'ingegnerizzazione di una soluzione. Qualcosa come DDD e / o altro. Formale o più informale. Essere più formale potrebbe anche essere considerato eccessivamente ingegneristico, specialmente in contrasto con le metodologie popolari di Agile.

Stai utilizzando il colore per distinguere determinate classi di entità e relazioni, quindi è un buon inizio. Potresti definire quei colori usando una legenda di qualche tipo. Anche le frecce di etichettatura sono generalmente una buona cosa quando si comunica l'architettura tramite diagrammi.

Ti sei concentrato principalmente sulle scelte tecnologiche per l'implementazione, che potremmo considerare parte dell'architettura logica e / o fisica.

C'è un'architettura di livello superiore che può essere descritta, se vuoi, che potrebbe andare all'architettura contestuale o concettuale.

Ad esempio, potresti documentare le tue strutture dati persistenti a livello concettuale o logico da una parte e, dall'altra parte, i comportamenti e le responsabilità del sistema e dei suoi componenti. Vari flussi di lavoro attraverso l'applicazione e i componenti.

Ad esempio, non c'è molta chiarezza su quale sia l'output del motore Regole, quando / come viene utilizzato; ha una relazione con l'applicazione principale ma non con le statistiche del giocatore, il che sembra possibilmente incoerente con la descrizione testuale.

In sintesi, i diversi database, senza razionalizzazione che li giustificano architettonicamente, potrebbero essere considerati di tipo ingegneristico (nel senso di un over building). D'altra parte, la quantità di dettagli trasmessa nel diagramma dell'architettura potrebbe essere considerata in ingegneria, senza alcuna documentazione aggiuntiva che accompagna il diagramma.