Dipendenze accettabili in un'architettura orientata ai servizi, interna a un team

Question

#1 da (1 voti)

6

In un'architettura orientata ai servizi, i sottosistemi possono dipendere l'uno dall'altro a diversi livelli:

Livello di database = > Chiavi esterne per rafforzare l'integrità dei dati tra i servizi di eliminazione e aggiornamento (in cascata) e le viste che utilizzano le tabelle di altri servizi per aumentare le prestazioni
Riutilizzo del codice = > come riferimenti DLL nella piattaforma .NET, per ridurre la quantità di codice e seguire DRY
Utilizzo del servizio = > Per rafforzare la centralizzazione aziendale; Ogni servizio può utilizzare qualsiasi altro servizio in uno schema simile a una mesh
Riuso UI = > Per facilitare la coerenza nell'interfaccia utente e aumentare la UX

Quale di queste dipendenze è incoraggiata e quali no?

code-quality coupling soa services

posta Saeed Neamati 02.09.2013 - 19:29

fonte

1 risposta

score 1 · Answer 1

Le dipendenze a livello di archivio dati sono pericolose. Dove possibile, preferisci un sottosistema per astrarre i dettagli. Altrimenti, preferisci creare una libreria di accesso ai dati che elabori i dettagli dell'accesso al datastore e assicuri la coerenza tra i servizi.
Il riutilizzo del codice dovrebbe essere incoraggiato, specialmente se si dispone di un sistema per distribuire coerentemente il codice riutilizzato.
L'utilizzo del servizio dovrebbe generalmente essere incoraggiato, ma se si osservano cicli di sviluppo, ciò può significare che alcuni componenti stanno facendo più di quanto dovrebbe, e la suddivisione di quel servizio in pezzi può essere in ordine.

Non sono sicuro di cosa significhi "riutilizzo dell'interfaccia utente", quindi non speculerò.