問題タブ [hexagonal-architecture]

雇用主が文書管理に使用する、社内で開発されたアプリケーションのコアを書き直す機会がありました。私の「コア」要件リストは次のようになります。

• さまざまな形式へのインポート/エクスポートを容易にします (ファイルのコレクション + かなり広範なメタデータが共通の要素です)。
• 複数のレベルで新しいフィールド (グローバルではなくデータ駆動型のフィールド) を簡単に追加できるようにする
• 古いシステムの基本的な前提に違反するいくつかの新しい機能を導入します (基本的に、ドキュメントを取り巻くメタデータの構造は根本的な変化を遂げています)。
• ドキュメントとメタデータの関係と規則を厳密に管理する能力を維持する

私はシリアライゼーションを世界との通信の主要な手段として使用するアーキテクチャをいじくり回してきましたが、これまでのところ結果に満足しています。ユーザー インターフェイス、XML ストア、およびさまざまなソースとシンクに対応するためにコア クラスを変更することなく、簡単にデータベースにアクセスできます。これは基本的に六角形のアーキテクチャであると考えています。すべてのシリアライゼーション ターゲットを同じように扱います (Serialize メソッドの注入可能な依存関係として)。

ただし、これはこのアプローチを使用した最初の試みであり、誰かが経験を持っているかどうか、もしそうなら洞察やアドバイスがあるかどうか疑問に思っています。

データをシリアル化するクラスがあります。このデータをJSONまたはおそらくYAMLとしてシリアル化したいと思うかもしれません。この場合、YAMLをJSONオブジェクトときれいに交換できますか？私は次のようなことができると思っていました。それは夢の裏切りですか？

Ruby で Web ベースのアプリケーションを設計しようとしています。フレームワークとデータベースを使用せずに、六角形アーキテクチャで DCI パラダイムを実装する単純なコア アプリケーションを開発しました。コアの六角形には小さな六角形と、Web、データベース、ログなどのアダプターがあります。すべての六角形は、データベースとフレームワークなしで単独で実行されます。このアプローチでは、データベースとは独立したデータベースモデルとエンティティクラスとの関係をどのように提供できますか。将来、フレームワークを Rails から Sinatra に、またはデータベースに変更したいと考えています。実際、このコア Hexagon で正確に分離されたレールと mongodb であるデータベース アダプターまたはフレームワーク アダプターをどのように実装できますか。何か案は？

たとえば、2 つのサービスを必要とするアプリケーションがあるとします。Application、Service1、Service2

このオニオン アーキテクチャに従って、余分なレベルの間接化を構築し、サービスの 1 つをアプリケーション サービスに昇格させ、もう 1 つをドメイン サービスに降格させる必要があります。

または、 と の両方に直接接続する必要がありApplicationますか?Service1Service2

別のレベルの間接化を使用すると、Applicationレイヤーへの依存、特に外部サービスへの依存を減らすことができます。「Paypal」、「Facebook」、「Cyber​​Source」を使用して、プログラミング パラダイムにより適したアプリケーション サービス アダプターを作成します。結局、すべての開発者がこれらの多種多様な API に慣れ親しんでいることは、生産性にとって非常に有害です。ファサード/アダプタは、アプリケーションをインフラストラクチャの変更から保護しながら、開発を容易にします。例えば。同社は Cyber​​Source で失敗し、代わりに Paypal を使用することにしました。幸いなことに、アプリケーションはシールドされており、アダプターを変更するだけで済み、他には何も必要ありませんでした。

とはいえ、アダプターは間違いなく柔軟性を失います。アプリケーションが複雑になるにつれて、アダプターもリークしやすくなります。次に、潜在的に 3 つの問題があります: 漏れやすい抽象化、怠惰なレイヤー (穴が多すぎるために十分に機能していないレイヤー)、および一般的な閉鎖原則の違反です。UI を変更する必要があるときはいつでも、アプリケーションだけでなく、アダプタも。

そしてService2、同じ会社内ですでに内部サービスになっている場合はどうなりますか? サブシステムごとにアダプターを作成する必要がありますか? あなたのチームが小さい場合はどうなりますか？多様なテクノロジー セットを備えたチームが数十ある場合はどうなるでしょうか。別の間接レイヤーを追加することと、単にサービスを直接呼び出すことの妥当性についてのガイダンスはありますか?

エンティティ フレームワークを使用して作業単位を実装し、完全な単位が実行された後にのみ変更をコミットする方法を理解していますが、これをさらに一歩進めるにはどうすればよいですか? たとえば、次のすべてが 1 つのトランザクションで発生する必要があります

電子メールの送信とデータベース内のユーザーの保存がすべて 1 つのトランザクション内で確実に行われるようにする方法がよくわかりません。どんなアドバイスでも大歓迎です

私は、Onion アーキテクチャ、Clean アーキテクチャ、Ports and Adapters などの名前を持つこの新しい種類のアーキテクチャを理解しようとしています。

ポートとアダプタを抽象化して、アプリケーションを特定のポートに適合させる場合、アプリケーション内からポートにエンティティを与えても問題ありませんか? または、ポートに合わせてエンティティも常に適応させる必要がありますか?

例：

Customer エンティティがあるとします。アプリケーションを使用する UI があります。私の UI は、Adapter を介して getCustomerById(123) を呼び出します。次に、アダプターがアプリケーションを呼び出し、注入されたリポジトリを使用して顧客を効果的に取得し、何らかのフォーマットとログを実行します。顧客の準備が整うと、UI に返されます。ここでの私の質問は、Customer オブジェクトがそのまま UI に返されるということです。これは、UI がコア プロジェクトの Customer クラスへの参照を持っていることを意味します。私のUIはその後、そのCustomerオブジェクトを使用して何かを行い、名前を変更するなどして、最終的にアダプターを再度呼び出してupdateCustomer(customer)を呼び出します。

これは大丈夫ですか？UI がアプリケーション コア内から Customer クラスを使用しても問題ありませんか。または、代わりに Customer を UICustomer などの新しい Customer オブジェクトに適応させ、代わりに UI をそれで動作させ、アダプター レベルで Customer と UICustomer の間を行き来する必要がありますか?

Alistair Cockburn の元の記事を含む、Ports & Adapters アーキテクチャに関するさまざまな情報源を読んだ後でも、「ポート」と「アダプタ」という用語の明確な意味についてまだ確信が持てません。特に、これらの概念を実装アーティファクトにマッピングする場合はなおさらです。

いくつかの情報源 (この投稿など) は、このアーキテクチャ パターンのポートが非常に外側のアーティファクトであり、その後にポートと心臓部にあるアプリケーションの間で変換する中間層のアダプターが続くことを示唆しています。

ただし、Cockburn の元の記事では、通信の方向に応じて、ポートがアダプター層の外側と内側に表示されます。

• インバウンド通信: 「イベントが外部からポートに到着すると、テクノロジ固有のアダプタがそれを使用可能なプロシージャ コールまたはメッセージに変換し、アプリケーションに渡します。」
• アウトバウンド通信: 「アプリケーションが送信するものを持っている場合、ポートを介してアダプターに送信し、受信テクノロジー (人間または自動) が必要とする適切な信号を作成します。」

実際、私にとっては、「すべて外側」のアプローチも「内側と外側」のアプローチも意味がありません。ポートは、通信の方向に関係なく、常にアプリケーションの隣に配置されるアーティファクトと見なされます。これは、ポートとアダプターの比喩とも一致します。シリアルポートを備えたデバイスを使用して、シリアルポートを備えていない別のデバイスをこれに接続するには、デバイスの観点からインバウンドおよびアウトバウンド通信を適応させるアダプターが必要です。

このアーキテクチャの実装に関して言えば、ポートの定義はアプリケーションの一部としてではなく、さまざまなアダプタがアプリケーションの「外部」にあると考えます。例）単一ポートの実装は、facade(インバウンド通信用のアダプターによって呼び出される) とinterface(アウトバウンド通信用のアダプターによって実装される) で構成されます。

ポートとアダプターという用語の正しい意味は何ですか? また、これらの概念を実装成果物にどのようにマッピングできますか?

アップデート：

私の理解に似たこの記事を見つけました。問題は、何らかの共通の合意があるかどうかです。