Sto lavorando a un refactoring di alcuni servizi e apprezzerei qualche critica sul mio approccio generale. Sto lavorando con tre sistemi di dati back-end e ho bisogno di esporre un'API front-end autenticata su http binding, JSON e REST per le app interne e l'integrazione con terze parti. Di seguito ho un'idea approssimativa che è un ibrido tra ciò che ho e dove intendo finire.
Intendo creare estensioni di guida per supportare questa architettura in modo che gli sviluppatori possano crearla rapidamente.
Ecco l'idea corrente per la nostra struttura:
- Servizio di routing WCF front-end (distribuito su più server IIS tramite il servizio di bilanciamento del carico hardware)
- Il bilanciamento del carico dei servizi dietro il routing viene gestito all'interno del servizio di routing, probabilmente round-robin
- Uno dei servizi sarà un token
- Associazioni multiple per-service esposte all'indirizzo JSON, REST e qualsiasi altra cosa succeda più tardi
- All in / out viene gestito tramite DTO POCO
- Utilizza l'unità per cercare quali servizi sono disponibili ed esporli
- I servizi front-end dietro il servizio di routing non fanno altro che esporre l'API e fare la conversione di DTO < - > Entity
- Unity inietta l'implementazione del servizio per consentire il mocking
- automapper per conversione DTO / entità
- Richiama i servizi WF dove la risposta è richiesta immediatamente
- Accoda a ESB per asincrono WF - ESB invocherà WF in seguito
- Livello WF della logica aziendale
- Esporre le stesse API come servizi front-end
- Implementa la business logic
- Avvolge il contesto della transazione dove necessario
- Chiama i servizi compositi / atomici
- Servizi compositi / atomici
- Esposto come WCF
- Un servizio per sistema di back-end
- Operazioni CRUD atomiche standard più operazioni composite
- Supporta il contesto della transazione
Le domande che ho sono:
- La separazione delle preoccupazioni sopra descritta è vantaggiosa? Il pensiero attuale è che ogni strato sottostante è un suo progetto, tranne il back-end, in cui ogni sistema ottiene un progetto. Il progetto ha un servizio host e tutti i servizi sono sotto una cartella di servizi. Le interfacce vivono in un progetto separato per ogni livello. DTO ed entità sono in due progetti separati in una cartella condivisa.
- Attualmente sto pianificando di creare servizi dedicati per funzionalità condivise come la registrazione e l'overload di cose come tracelistener per chiamare quei servizi. È un approccio valido?
- Altri suggerimenti / commenti?