Abbiamo progettato un'applicazione web a 3 livelli per un'applicazione di finanziamento.
Il livello aziendale è diviso ulteriormente in livelli come gestore, helper, livelli utili per modulare il codice e isolare le diverse funzioni tra core business e codice non business l'uno dall'altro
Il livello utente ha funzioni non aziendali che sono richieste durante un particolare processo, ad es. DateUtils.java, EncryptionUtil.java etc
Il livello di supporto ha una logica aziendale specifica per determinati processi di business e non richiesta in altri processi aziendali, ad es. SomeThirdPartyInterestCalculationHelper.java, SpecificRequestBuilder.java
Il livello manager ha un processo aziendale che controlla il flusso e implementa alcune parti della logica aziendale, ad es. CustomerAccountManager.java ha diversi metodi per le operazioni CRUD per l'account cliente. Chiama diversi aiutanti, programmi di utilità, DTO ecc. E porta a termine il lavoro. Implementa anche alcuni elementi della logica aziendale. Quindi, esegue un mix di ruoli BPM e parti della logica dei processi aziendali principali.
Poiché i processi diventano complessi e più lunghi, il mio livello manager è in crescita e non sembra un codice ben organizzato.
Voglio livelli separati che svolgono ruoli specifici, ad esempio controller dei processi di business, esecuzione dei processi di business (core business logic), operazioni CRUD che sono specifiche del DB, helper (specifici per i processi), logica non business
Quale può essere un modello di design migliore per raggiungere questo obiettivo?
Sto provando i modelli di Business Objects per isolare diverse parti della logica aziendale e accoppiarle con il modello di servizio dell'applicazione.
Quindi, per l'esecuzione di un processo aziendale, avrei:
- ApplicationService - Sarebbe un puro controllore di processi business che chiama oggetti business diversi e controlla l'esecuzione in base ai risultati dei metodi BO
- BusinessObject1 - Logica di business principale in diversi metodi - Chiamato da ApplicationService
- BusinessObject2 - Logica aziendale principale in diversi metodi - Chiamato da ApplicationService (se BusinessObject1 diventa più grande o BusinessObject 1 e 2 possono eseguire funzioni aziendali specifiche)
- IntegrationBusinessObject - Per chiamare altri servizi di terze parti richiesti nei processi aziendali
- DomainEntityBusinessObject - L'operazione CRUD per una particolare entità di dominio richiesta nel processo ... avrà anche alcuni controlli di livello aziendale richiesti prima o dopo le operazioni CRUD
- Schede - Per convertire i formati per servizi di terze parti - Può essere chiamato da IntegrationBusinessObject
L'idea è rendere le classi più compatte e svolgere specifiche funzioni aziendali. Inoltre, controlla il processo da una singola classe (Application Service) in modo che la modifica del processo possa essere più semplice.
Questo design è gestibile e scalabile?