Posso usare i modelli di Application Service e Business Objects per semplificare e meglio eseguire i processi di biz?

1

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:

  1. ApplicationService - Sarebbe un puro controllore di processi business che chiama oggetti business diversi e controlla l'esecuzione in base ai risultati dei metodi BO
  2. BusinessObject1 - Logica di business principale in diversi metodi - Chiamato da ApplicationService
  3. 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)
  4. IntegrationBusinessObject - Per chiamare altri servizi di terze parti richiesti nei processi aziendali
  5. 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
  6. 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?

    
posta Suraj 07.05.2018 - 08:06
fonte

1 risposta

1

Il design è buono, ma assicurati di evitare di sovraccaricare il manager con attività non rilevanti.

Il manager dovrebbe svolgere solo attività di orchestrazione, altrimenti è necessario creare nuove classi che si interessino a comportamenti specifici e attività di non orchestrazione. Per lo più questo sarà nel tuo livello di supporto.

In questo modo hai un livello gestibile.

Inoltre, per favore non separare le classi per dimensione, ma solo per rilevanza. quindi ogni volta che vedi l'attività non è direttamente rilevante per questa classe, crea una nuova classe e usala nella tua classe originale. questo mantiene le classi più manutenibili e comprensibili.

    
risposta data 07.05.2018 - 08:19
fonte

Leggi altre domande sui tag