Panoramica rapida del dominio
Nel dominio della contabilità, ci sono i seguenti concetti distinti ma correlati:
- un account identifica gli "argomenti" finanziari di base che devono essere considerati;
- una transazione o un posting rappresenta un evento aziendale che aggrega diversi cambiamenti di valori agli account;
- a (posting / transazione) riga o elemento è una parte di una transazione che documenta una modifica di valore che influenza esattamente un account;
- un saldo del conto riepiloga il valore di un account, tenendo conto di tutti gli elementi pertinenti;
- un ledger è un insieme ordinato cronologico di transazioni. Il libro mastro generale è l'insieme di tutti gli elementi, ordinati cronologicamente per account.
Al di là dei concetti di base (e qui un po 'semplificati), c'è una certa logica di business da assicurare in tutti i casi:
- la somma di tutti i debiti e i crediti di una transazione deve essere uguale (o se i tuoi crediti rappresentano numeri negativi, la somma deve essere 0).
- di conseguenza, anche la somma di tutti i debiti in un libro mastro o nella contabilità generale sarà ugualmente uguale.
- il totale degli articoli per un account nella contabilità generale deve sempre essere uguale al saldo di tale account
Analisi delle alternative di progettazione
L'approccio attuale è molto sensibile alla qualità di ogni applicazione. Ogni applicazione potrebbe infrangere la regola e creare confusione nei conti di tutti gli altri.
L'approccio Linq garantisce una migliore coerenza tra tutte le tue applicazioni. Ma sei sicuro di poter garantire l'aggiornamento coerente di tutti i tuoi nuovi oggetti di dominio, soprattutto se dovessi aggiornare un'applicazione e dimenticarti di ricompilare / distribuire gli altri?
L'approccio più astratto sembra avere un'architettura più pulita. Inoltre implementa un suono separazione delle preoccupazioni :
- Le 10 applicazioni implementano ciascuna la propria logica di applicazione specializzata (vendite, acquisti, gestione delle scorte, ecc.)
- La logica di contabilità di dominio comune è garantita dal livello di servizio della contabilità. Se testate a fondo il vostro livello di servizio, potreste quindi essere sicuri che nessuna applicazione potrebbe rovinare gli account (evento se si tratterebbe di una versione precedente dell'applicazione che qualcuno ha dimenticato di ricompilare). In ogni applicazione, gli sviluppatori devono solo preoccuparsi di registrare le giuste transazioni e concentrare i test solo sulla logica specializzata dell'applicazione, senza dover comprendere i dettagli della contabilità.
- Se vuoi migliorare la tua logica di contabilità e ad esempio aggiungere alcune funzionalità di registrazione (ad esempio su richiesta dei revisori finanziari), dovresti semplicemente farlo nel tuo livello di servizio, e sei sicuro che tutto il l'applicazione funzionerà come previsto con la nuova funzionalità.
Quindi, alla fine, le applicazioni non dovrebbero più eseguire alcun calcolo contabile: dovrebbero semplicemente interrogare il servizio per ottenere gli account da utilizzare, inviare alle transazioni coerenti del servizio (usando qualche tipo di DTO ) e interrogare i saldi dei conti se necessario.