Quando si progetta un'API aziendale, quale livello è appropriato per separare le librerie?

Naviga le tue risposte
4

Supponiamo di sviluppare un sistema REST per un'azienda aziendale per esporre le risorse aziendali in un'applicazione basata su Java. Alla fine hai una sola applicazione web e librerie di dominio. La mia domanda è dove componenti e servizi dovrebbero vivere in queste librerie di dominio e cosa dovrebbe esistere nell'applicazione stessa.

Per un'azienda ipotetica potremmo avere diverse aree di dominio.

  • Relazioni con i clienti
  • Ordini di vendita dei clienti
  • Fabbricazione
  • Struttura del prodotto
  • Catena di fornitura
  • Warehousing

Dati questi domini avremmo oggetti dominio e servizi oggetto per la persistenza. Potremmo quindi separarli ulteriormente in implementazioni

  • Relazioni con i clienti
  • Relazioni con i clienti - JDBC Impl
  • Ordini di vendita dei clienti
  • Ordini cliente - JDBC Impl
  • Fabbricazione
  • Produzione - JDBC Impl
  • Struttura del prodotto
  • Struttura del prodotto - JDBC Impl
  • Catena di fornitura
  • Catena di fornitura - JDBC Impl
  • Warehousing
  • Magazzino - JDBC Impl

Ora sta iniziando a sembrare complesso solo a causa del numero di singole librerie che gestiamo. Mi chiedo se abbiamo persino bisogno di separarci da un tale livello e potremmo semplicemente avere i tre.

  • Business - Interfaccia
  • Business - JDBC Impl
  • Applicazione REST

La mia seconda parte della mia domanda riguarda le classi di servizio e le classi di gestione che dovrebbero vivere. Dato il nostro Magazzino di cui sopra abbiamo bisogno di oggetti di dominio per rappresentare pick-facce, una classe DAO per gestire l'oggetto pick-face e, infine, un componente di servizio per la nostra applicazione di riposo. Per questo potremmo vedere la seguente struttura.

  • Warehousing
    • PickFace
    • PickFaceDAO
  • Magazzino - JDBC Impl
    • JdbcPickFaceDAO
  • Applicazione ReST
    • PickFaceController

Da un lato PickFaceController è il migliore all'interno dell'applicazione ReST in quanto l'applicazione può quindi gestire manualmente i servizi per questo controller e potrebbe essere necessario personalizzare la configurazione.

D'altro canto, PickFaceController potrebbe essere migliore nel progetto Warehousing poiché riguarda solo il modulo di magazzino, tuttavia l'applicazione ReST potrebbe teoricamente utilizzare i localizzatori di servizio per trovare servizi in altre librerie.

SO quali sono gli approcci di successo utilizzati? Quando sai quando sei andato lontano nel separare o non fatto abbastanza? Come fai a sapere qual è il posto migliore dove mettere qualcosa?

    
posta Brett Ryan 24.08.2012 - 06:14
fonte

1 risposta

6

Dovresti dare un'occhiata a Onion Architecture: funziona molto bene con la progettazione basata sul dominio.

In sintesi, Onion Architecture sostiene che si sovrappone la propria applicazione a meno-dipendente / più longevo alla vita più dipendente / più breve. Le tue classi di dominio con interfacce repository rimarrebbero all'interno del core mentre le implementazioni specifiche risiederanno in un livello esterno.

Tipicamente, avresti qualcosa di simile (in alto non ci sono dipendenze, tutto sotto dipende da cosa c'è sopra):

  • Funzionalità principali comuni / condivise
  • Core Layer - Modelli di dominio, servizi di dominio, interfacce
  • Livello applicazione - Livello orchestrazione e anti-corruzione
  • Livello infrastruttura - Tipicamente implementazioni concrete di interfacce di dominio
  • Presentation Layer

L'idea è che la funzionalità di base comune / condivisa è disponibile ovunque (per lo più gli helper, non dovrebbero contenere la logica di dominio di per sé).

I livelli di applicazione e infrastruttura dipenderanno dal core layer e dalle funzionalità di base comuni / condivise.

Il Presentation Layer dipende dall'applicazione, dall'infrastruttura e dai core core condivisi / condivisi ma non direttamente ontop del Core Layer per garantire l'anti-corruzione.

Potrebbero esserci più di un livello applicazione: dipende dal numero di endpoint che potresti avere (un livello applicazione potrebbe essere un servizio Web). Non vuoi che il tuo livello di presentazione dipenda direttamente dai tuoi modelli di dominio principale perché svaluta il singolo principio di responsabilità (la logica di dominio dovrebbe applicarsi ai modelli di dominio - dati gli oggetti di dominio la responsabilità degli oggetti di trasferimento dati impone determinati limiti all'implementazione della logica di dominio ).

Spero che l'orientamento valga per te. Non posso esprimere il giudizio su come dovresti suddividere il tuo progetto in diverse librerie perché ciò dipenderebbe da altri fattori.

Alla fine non c'è niente che ti impedisca di metterlo tutto dentro un singolo assemblaggio. In genere, li dividerei per contesto limitato (autonomo) al fine di garantire l'inversione della dipendenza su un livello di separazione logica. Ci sono anche utility disponibili là fuori per combinare più librerie in una singola per la distribuzione.

    
risposta data 24.08.2012 - 12:45
fonte

Leggi altre domande sui tag

Aggiunta di funzionalità di base (ereditate) alle classi che non si controllano Qual è il modo normale in cui gli algoritmi di apprendimento automatico sono integrati nei programmi normali?