Domanda di architettura dell'applicazione ad alto livello

Naviga le tue risposte
2

Quindi voglio davvero migliorare il modo in cui modifico il software che codifico. Voglio concentrarmi sulla manutenibilità e sul codice pulito. Come puoi immaginare, ho letto molte risorse su questo argomento e tutto ciò che sta facendo mi rende più difficile stabilirmi su un'architettura perché non posso mai dire se il mio progetto è quello che ha più esperienza il programmatore avrebbe scelto.

Quindi ho questi requisiti:

  • Dovrei collegarmi a un unico fornitore e scaricare i moduli di invio dalla loro API. Li chiameremo CompanyA .
  • Dovrei quindi mappare tali invii a uno schema adatto per l'invio a un altro fornitore per l'integrazione con il fornitore di servizi di posta elettronica. Li chiameremo CompanyB .
  • Dovrei quindi inviare tali risposte all'ESP ( CompanyB ) e poi istruire l'ESP a inviare una email a quel mittente.

Quindi in pratica sto copiando i dati da un servizio web a un altro e poi eseguo un'azione su quest'ultimo servizio web.

Ho identificato un paio di servizi di alto livello:

  • Il servizio che scarica i dati da CompanyA . Ho chiamato questo CompanyAIntegrator .

  • Il servizio che invia i dati a CompanyB . Ho chiamato questo CompanyBIntegrator .

Quindi le mie domande sono queste:

  1. È un buon design? Ho cercato di separare le preoccupazioni e sto pianificando di utilizzare il modello di facciata per rendere gli integratori intercambiabili se i produttori cambiano in futuro.

  2. Le mie convenzioni di denominazione sono accurate e significative per te (chi non sa nulla di specifico del progetto)?

  3. Ora che ho questi servizi, dove dovrei fare il lavoro di prendere l'output da CompanyAIntegrator e ottenerlo nel formato per l'input in CompanyBIntegrator ? Va fatto bene in main() ?

  4. Hai qualche indicazione generale su come codificherai qualcosa del genere? Immagino che questo scenario sia comune per noi ingegneri, specialmente quelli che lavorano nelle agenzie.

Grazie per l'aiuto che puoi dare. Imparare a progettare bene l'architettura è davvero ingarbugliato.

    
posta Jesse Bunch 31.08.2012 - 02:41
fonte

3 risposte

2

Mantengalo semplice. Scrivi classi ben modulari che separano le preoccupazioni. I nomi delle tue classi vanno bene, e hai la giusta idea che i due "integratori" non dovrebbero conoscere l'uno dell'altro e una terza classe dovrebbe fare chiamate in loro per fare il lavoro. Non lo farai in main () se si tratta di una web app, main non è nemmeno esposta.

Non mi preoccuperei delle facciate. Anche se i fornitori vengono sostituiti, i nuovi fornitori non avranno API, schemi e provider di posta che forniranno necessariamente una mappatura pulita per la facciata o l'interfaccia. Quindi dovresti scrivere il codice client su un livello astratto, che non è necessario ora (ottimizzazione prematura), e che probabilmente dovrai riscrivere in futuro in ogni caso.

    
risposta data 31.08.2012 - 09:22
fonte
3

imho i nomi non sono buoni. Che cosa ti dice CompanyBIntegrator ? che è un'integrazione. Ma ti dice cosa fa l'integrazione? No.

IYourEntityDownloader o qualcosa del genere è meglio. Ti dice cosa fa.

Per quanto riguarda il processo, vorrei fare qualcosa di simile a questo (soc):

  1. Avere un lavoro che scarica le informazioni e memorizzarle in un archivio dati (db, file flat, memoria ecc.)
  2. Avere un lavoro che elabora le informazioni in base alle regole aziendali e quindi memorizza i risultati in un altro archivio dati
  3. Avere un lavoro che prende le informazioni elaborate e caricarle nella società b.

Con questi tre passaggi puoi spendere ogni singolo passaggio quanto vuoi senza intaccare le altre parti. Potresti anche utilizzare tre server diversi (o centinaia per questo).

Puoi anche iniziare a scaricare informazioni da una fonte, ma caricare su cinque destinazioni. Anche le altre parti non ne sono consapevoli poiché hanno responsabilità chiare.

    
risposta data 31.08.2012 - 09:31
fonte
1

Penso che tu sia sulla strada giusta per separare la logica e le azioni da eseguire su questi servizi. Jgauffin ha ragione affermando che dovresti dare agli "integratori" una convenzione di denominazione migliore. i_objectName_whatObjectDoes è un buon inizio e rende molto più facile per i futuri sviluppatori sapere quale oggetto fa quale funzione.

Per quanto riguarda la separazione del codice, potresti voler utilizzare DTO, Data-layers e Object Manager. Questo rende la tua soluzione più leggibile. Ricordarsi di conservare DTO, Datalayers e Manager in progetti separati e includerli nella soluzione.

    
risposta data 31.08.2012 - 16:58
fonte

Leggi altre domande sui tag

Sovraccarico pulsanti di interfaccia, quali sono le migliori pratiche? Standard di codifica stabiliti per il codice pl / pgsql