コンポーネントダイアグラムでバックエンドとDBの関係をどのように表すのですか？
コンポーネントダイアグラムが表示する内容を完全に理解しているとは思いません。 airbnbに似た、ホームステイ予約システム用の3層Webアプリケーションがあるとします。 3つの主要コンポーネントは明確です。クライアント、webapp /バックエンド、およびDB。しかし、コンポーネントダイアグラムの描画に関しては、インターフェイスに名前を付ける方法がわかりません。
たとえば、 here とすると、次の図が表示されます。
コンポーネント図は 構造図 に該当しますが、「CustomerLookup」は構造的な関係というよりユースケースのように思えます。
重要なアプリケーションがある場合、バックエンドはDBをはるかに複雑に使用します。ユーザーの検索だけでなく、ユーザーストレージ、宿泊施設の検索なども行います。これらのユースケースをすべて図に描くことは想定していないと思います。 「永続性」として非常に一般的な名前を使用するか、エンティティ（ユーザー、宿泊施設など）ごとに1つのインターフェースを使用する必要がありますか？
コンポーネントダイアグラムよりも概念図でその情報を表現する方が適切です。意味：2つのボックスを描画し、それらを矢印付きの線で直接接続します
また参照してください： 概念図@ウィキペディア
あなたが話しているのは、システムの非常に高いレベルのビューです。コンポーネント図は、このような高レベルのビューには適していません。コンポーネント図は、コンポーネントで使用されるすべてのパブリック機能を示すために必要です。そのため、コンポーネント間の相互作用を一目で理解するのに役立ちます。だから彼らは詳細にする必要があります。
おそらく、データベース、特に正規化されたリレーショナルデータベースは、コンポーネントとして見た場合、非常に幅広いインターフェイスを提供するという事実から混乱が生じます。パブリックテーブル、ビュー、およびストアドプロシージャも、それ自体がインターフェイスを表します。ささいなデータベースを除いて、インターフェースシンボルで各エンティティを表現することは、抽象化の有用なレベルではありません。それは、すべてのDBエンティティの非構造化リストになるだけです。
ここで、アクセスするアプリケーション（例のバックエンドアプリのように）が1つのブラックボックスであり、さまざまな論理コンポーネントに簡単に分割できず、全体が意のままに任意にDBモデルにアクセスする場合は、 DBを1つのインターフェースとして、1つのシンボルで、特定の名前なしでモデル化します。私は実際には名前を省略することを検討します。「持続性」のような名前は、名前がないこと以上の情報を提供しません。
ただし、アクセスしているクライアントが多くの異なるアプリケーションであり、それぞれがDB内のエンティティの異なるサブグループを担当し、それぞれが論理的または物理的なコンポーネントである場合、それぞれを個別のインターフェースでDBをモデル化することは理にかなっています。各サブグループ、およびそれぞれがその目的を他と区別する一意の名前を持つ。または、各サービスが独自にデータベースまたはデータストレージを持つマイクロサービスアーキテクチャがある場合、各サービスとそのDBをコンポーネントとしてモデル化できます。このため、各インターフェースシンボルは、1つのサービス/コンポーネントのAPI全体を表します。
つまり、コンポーネント図はコンポーネントベースのアーキテクチャに最適です。アプリケーションまたはデータベースに十分な部分構造がない場合、またはこの部分構造が表示されない抽象化レベルでモデル化する場合、コンポーネント図は特に役立ちません。