問題タブ [hexagonal-architecture]

階層化されたアーキテクチャ (オニオン、六角形、クリーンなど) を使用してソフトウェアを構築した経験があり、よく知っている方にお願いしています。ソフトウェア アーキテクチャについて Google で検索すると、人々はさまざまな視点を持っており、同じアーキテクチャをさまざまな方法で説明しています。

条項

質問を読む前に、いくつかの用語が混乱する可能性があるため、以下でそれらを定義しています。それらの「正しい」定義があるかどうかはわかりませんが、インターネットからこれらの情報を収集しました. 私が誤解している場合はお知らせください。

ドメイン層: エンタープライズ/ビジネス ロジックを含み、ドメイン モデルを使用します。中心に位置し、ドメイン モデル以外の他のレイヤーには依存しません。

アプリケーション レイヤー: アプリケーション ロジックを含み、インフラストラクチャ レイヤーから DTO を受け入れ、View Model を転送します。

DTO (Data Transfer Object) : レイヤー間のデータ転送に使用されるクラス、JSON 文字列など。純粋なデータ コンテナーの場合があります。

VM (View Model) : アプリケーション層からプレゼンテーション層に渡される DTO。

DO (ドメイン モデル) : ドメイン層で使用されるクラス、JSON 文字列など。純粋なデータ コンテナーの場合があります。

VO (値オブジェクト) : データベース エンティティ (データベース行)、またはデータベースが使用するデータ形式。データベース層からアプリケーション層に転送できます。

まとめ

オニオン、六角形、またはクリーン アーキテクチャでは、ドメイン レイヤーが中心にあります (つまり、ドメイン レイヤーは、データを他のレイヤーに転送したり、上位レイヤーからデータを受け取ったりするために使用されるドメイン モデル以外のレイヤーに依存しません)。

これは、ドメインが使用するドメイン モデル (DTO、POJO、VO など) が、データベースが永続データの保存に使用するモデルとは異なる可能性があることを意味します。

分かりやすく説明できるように図を描いてみました。

Q1 :

2枚目の画像の赤い部分を見てください。

従来の階層化または n 層アーキテクチャとは異なり、ドメイン層が中心にある場合、ドメイン モデルはデータベース エンティティ (行) よりも多くのプロパティ (または異なるプロパティ) を持つことができますか?

たとえば、ドメイン層でPersonというクラスが使用されているとします。ユーザーは、サーバーに登録されているすべての人物の写真を要求します。データベースにすべての人の名前だけが含まれていると仮定しましょう。ただし、他の Web サーバーを使用して、人物の写真を名前で要求する場合があります。したがって、アプリケーション層はデータベースからすべての名前を読み取り、それらの名前を使用して、HTTP 要求を介して他の Web サーバーからすべての画像を取得します。その後、名前と写真を含むPersonのリストがビュー モデル (DTO) としてユーザーに送信されます。

Q2 :

永続層は、データベース、ファイル システム、その他の Web API などで構成されている場合があります。

プレゼンテーション レイヤー レイヤーは、Web サイト、デスクトップ アプリ、モバイル アプリ、Web API などです。

どちらのレイヤーもインフラストラクチャ レイヤーの一部であり、アプリケーション レイヤーに依存しますが、アプリケーション レイヤーはドメイン レイヤーにのみ依存します。

アプリケーション層がプレゼンテーション層からのリクエストを受け付けている場合、プレゼンテーション層はアプリケーション層を呼び出し、プレゼンテーション層はアプリケーション層を認識しているため、問題はありません。

ほとんどの場合、アプリケーション層は永続層からデータを取得する必要があります。

アプリケーション層は、永続層のクラスを認識していないため、依存関係なしに永続層を呼び出すことはできません。

これは私がこれまで理解している方法ですが、データがどのように流れ、下位層から上位層への通信がどのように行われるかを明確に説明してもらえますか?

コードを書きたい人には、C# がおすすめです。