Partizionare le risorse dell'API REST in aree basate su domini aziendali

Naviga le tue risposte
8

In un'API REST di un'importante applicazione che copre diversi domini correlati, ha più senso suddividere le risorse in "aree" in base al dominio aziendale a cui appartengono o è meglio mantenere un singolo modello?

Ad esempio, ci sono sottodomini "Vendite" e "Spazio pubblicitario". Gli utenti del sistema in genere si preoccupano solo di un dominio alla volta, ma sono possibili eccezioni. Esiste un concetto "Articolo" che esiste in entrambi i domini in modo da poter implementare la risorsa "elemento" in due modi diversi.

  1. hanno risorse diverse per rappresentare il concetto in ciascun dominio, ogni risorsa contiene solo i dati rilevanti:

    / vendite / oggetti /: id

    / inventario / oggetti /: id

  2. avere una singola risorsa con tutti i dati da utilizzare in tutti i contesti:

    / oggetti /: id

Ci sono anche molte risorse che appartengono solo a uno dei domini.

professionisti delle "aree"

  • più facile capire l'API per gli utenti che si interessano solo di un singolo dominio
  • più facile da implementare le risorse (meno materiale da leggere / aggiornare alla volta)
    • Le risorse
  • possono essere più specializzate / ottimizzate per ogni particolare dominio
  • capacità di controllare l'accesso alle risorse a un livello più granulare

professionisti di un singolo modello unificato

  • nessuna risorsa duplicata per concetti che appartengono a più di un dominio
  • se un utente deve lavorare con più domini, dovrà solo utilizzare una singola API che copra tutte le sue esigenze

Il partizionamento API è descritto sopra come un modo valido per ridurre la complessità del contratto e dell'implementazione API? Non l'ho mai visto menzionato da nessuna parte.

Ci sono altre cose che devono essere prese in considerazione per prendere una decisione a favore di entrambi gli approcci?

    
posta astreltsov 22.04.2015 - 10:47
fonte

2 risposte

6

Penso che questo sia l'adattamento perfetto per Contesto limitato modello da Domain Driven Design.

I modelli di grandi dimensioni non si adattano bene, è meglio dividerli in modelli più piccoli (contesti limitati) e dichiarare esplicitamente le loro relazioni (entità comuni, interazioni tra contesti limitati ecc.)

In questo caso avresti due contesti limitati (vendite e inventario) con una risorsa condivisa (elemento). L'interpretazione dell'elemento nel contesto di vendita può essere leggermente diversa rispetto al contesto dell'inventario e va benissimo.

Per usare questo modello, dovresti:

  • identifica i confini di diversi contesti (che in parte hai fatto creando sottotubi / vendite / e / inventario /)
  • identifica le risorse condivise (elemento) e descrive esplicitamente qual è l'interpretazione della risorsa in diversi contesti limitati
  • identifica le interazioni tra i contesti limitati (che è probabilmente fuori dal campo di applicazione di questa domanda)

Nota su

pros of a single unified model: no duplicated resources for concepts that belong to more than one domain

Dal punto di vista REST, la risorsa non è duplicata. Una risorsa può essere identificata da più URI, ognuno può avere rappresentazioni diverse (adattandosi a un determinato contesto limitato).

    
risposta data 26.04.2015 - 13:23
fonte
0

Penso che la regola generale dovrebbe essere la seguente.

Se un elemento in sé è impensabile senza essere correlato a vendite o inventario, dovresti optare per l'opzione 1.

Se un elemento può esistere senza alcuna relazione con le vendite / inventario o questa relazione non è molto strong nella tua architettura, puoi optare per l'opzione 2.

    
risposta data 22.04.2015 - 17:31
fonte

Leggi altre domande sui tag

Relazione tra la riga della cache e la pagina di memoria Nel modello MVP la Vista istanzia un oggetto Modello basato sui contenuti dell'interfaccia utente, o semplicemente passa questi contenuti come parametri al Presenter?