La tua confusione deriva probabilmente dal fatto che i database, in particolare i database relazionali normalizzati, quando visti come componenti, in genere forniscono interfacce molto ampie. Qualsiasi tabella pubblica, qualsiasi vista e talvolta anche stored procedure rappresenta un'interfaccia a sé stante. Quindi, ad eccezione dei banali database, la rappresentazione di ogni entità con un simbolo di interfaccia non è un utile livello di astrazione: diventerebbe semplicemente un elenco non strutturato di tutte le entità DB.
Ora se la tua applicazione di accesso (come l'app di backend del tuo esempio) è solo una scatola nera, non facilmente da suddividere in diversi componenti logici, e l'intera cosa accede al modello di DB arbitrariamente a volontà, di quanto tu non possa fare molto meglio della modellazione del DB come un'unica interfaccia, con un solo simbolo e nessun nome specifico. In realtà considererei di omettere qualsiasi nome, un nome come "persistenza" in realtà non fornisce più informazioni che nessun nome.
Tuttavia, se i client di accesso sono molte applicazioni diverse, ciascuna responsabile di un sottogruppo diverso delle entità nel DB e ciascuna di esse un componente logico o fisico, può avere senso modellare il DB con le singole interfacce, ciascuno per ciascun sottogruppo e ognuno con un nome univoco che distingue il suo scopo dagli altri. Oppure, quando esiste un'architettura di microservizio, in cui ogni servizio ha un database o una memoria dati autonoma, ogni servizio insieme al proprio DB può essere modellato come componente. Per questo, ogni simbolo di interfaccia rappresenterà l'intera API di un servizio / componente.
Quindi, in breve, i diagrammi componenti sono più adatti per architetture basate su componenti . Se l'applicazione o il database non hanno una sottostruttura sufficiente o se lo si modella a un livello di astrazione in cui questa sottostruttura non è visibile, un diagramma di componenti non è particolarmente utile.
