Repository che esegue internamente chiamate API - DDD

Le interfacce, i protocolli e l'ereditarietà in generale non sono adatti per descrivere tassonomie di oggetti. Cioè un'interfaccia che descrive "Un repository QueryablePanoramas è un tipo di repository Panoramas che consente anche di elencare tutti i panorami disponibili" è raramente utile.

Invece, è meglio usare le interfacce per descrivere come alcuni oggetti saranno usati . Se i tuoi repository sono consumati da un codice che esegue solo query sul repository e un codice che scrive anche nel repository, allora è logico dividere tali preoccupazioni separate in interfacce separate (questo è il principio di segregazione dell'interfaccia). Ma qui sembra che i consumatori abbiano bisogno di un accesso completo in lettura / scrittura / query ai repository. Quindi, la creazione di più interfacce non aiuta.

Si noti il problema che non tutte le origini dati sono in grado di supportare tutte le operazioni del repository. Ma quelle fonti di dati non sono necessariamente le stesse del repository. Qui, sembra che l'API di Street View sia in grado di fornire alcune funzionalità, ma deve essere abbinata a un archivio persistente per essere completamente funzionale nella tua applicazione. Quindi, sarebbe compito del repository fare quella connessione. Per esempio. (pseudocodice b / c Non so Swift):

struct PanoramaRepository {
  private let storage = ...
  private let streetView = ...

  // first search locally cached panoramas, otherwise fall back to Street View
  public function findOne(lat, lon): Panorama? {
    if (lat, lon) in storage {
      return storage[lat, lon]
    } else {
      return streetView.search(lat, lon)
    }
  }

  // only return the saved panoramaas
  public function findAll(): [Panorama] {
    return storage
  }

  ...
}

Se questo è possibile dipende dal contratto di quel repository. Per esempio. se c'è qualche invariante che il panorama restituito da findOne() deve essere nella lista restituita da findAll() , questo non funzionerà. Ma quando non esiste alcuna restrizione di questo tipo, il repository può essere astratto sulle specifiche API e meccanismi di archiviazione utilizzati.

Ci sono un paio di varianti per fare ciò, a seconda delle tue esigenze. Ad esempio, è possibile utilizzare il pattern decoratore per aggiungere facoltativamente il supporto Street View a un repository esistente:

struct PanoramasWithStreetView(baseRepository: Panoramas) {
  private let streetView = ...

  // use street view as a fall back if the repository doesn't return a result
  public function findOne(lat, lon): Panorama? {
    if let panorama = baseRepository.findOne(lat, lon) {
      return panorama
    } else {
      return streetView.search(lat, lon)
    }
  }

  // all other methods just delegate to the base repository
  public function findAll(): [Panorama] { return baseRepository.findAll() }
  ...
}

let panoramas: Panoramas = PanoramasWithStreetView(PanoramasInDatabase(...))

Potrebbe essere più elegante da implementare, ma aggiunge ulteriore flessibilità che può rendere la tua applicazione più fragile. Per esempio. potresti utilizzare accidentalmente un repository che non utilizza l'API di Street View.

Infine, considera se l'uso dell'API di Street View appartiene davvero a un repository. Se questa API non è solo un'origine dati tra le tante, ma esiste una logica aziendale che tratta i panorami dall'API in modo diverso rispetto ai panorami archiviati localmente, quindi l'estrazione del codice API in un servizio separato potrebbe essere migliore. L'idea del contesto limitato potrebbe aiutare. A quale contesto appartengono le chiamate API? Si tratta di un dettaglio di implementazione dal punto di vista del dominio del problema principale, in modo che queste chiamate API appartengano al contesto "Archiviazione panorama"?

A seconda delle scelte di progettazione, potresti anche dover riconsiderare se la tua definizione di Panorama è sufficiente.

• Se i panorami possono provenire da più fonti, è difficile specificare un determinato ID. Gli ID dovrebbero avere uno spazio dei nomi (come gli URI), descrivere semplicemente il contenuto (non modificabile!) (Un hash come in blockchains, Git o IPFS), o garantire l'unicità combinando spazio dei nomi, timestamp, casualità e ID locale (come UUID).
• Considera se Panorama rappresenta un'immagine che può essere visualizzata direttamente, un'immagine localmente salvata o un localizzatore di immagini più astratto (come un URL). Quando si utilizza un percorso file, considerare se questo percorso file è persistente o semplicemente una cache temporanea.