翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
変更への適応
ソフトウェアシステムは複雑になる傾向があります。その理由の 1 つは、ビジネス要件を頻繁に変更し、それに応じてソフトウェアアーキテクチャを適応させる時間が少ないことです。もう 1 つの理由は、プロジェクトの開始時にソフトウェアアーキテクチャを設定して頻繁な変更に適応するための投資が不十分であることです。理由に関係なく、ソフトウェアシステムは、変更を行うことがほとんど不可能なほど複雑になる可能性があります。したがって、メンテナンス可能なソフトウェアアーキテクチャをプロジェクトの最初から構築することが重要です。優れたソフトウェアアーキテクチャは、変更に簡単に適応できます。
このセクションでは、非機能要件やビジネス要件に簡単に適応する六角形アーキテクチャを使用して、保守可能なアプリケーションを設計する方法について説明します。
ポートとアダプターを使用した新しい非機能要件への適応
アプリケーションの中核となるドメインモデルは、ビジネス要件を満たすために外部から必要なアクションを定義します。これらのアクションは、ポートと呼ばれる抽象化によって定義されます。これらのポートは個別のアダプターによって実装されます。各アダプターは、別のシステムとのやり取りを担当します。たとえば、データベースリポジトリ用のアダプターが 1 つあり、サードパーティー API とやり取りするためのアダプターがもう 1 つあるとします。ドメインはアダプターの実装を認識していないため、あるアダプターを別のアダプターに置き換えるのは簡単です。たとえば、アプリケーションは SQL データベースから NoSQL データベースに切り替えることができます。この場合、ドメインモデルで定義されたポートを実装するために、新しいアダプターを開発する必要があります。ドメインにはデータベースリポジトリへの依存関係がなく、抽象化を使用してやり取りするため、ドメインモデルで何も変更する必要はありません。したがって、六角形アーキテクチャは非機能的な要件に簡単に適応します。
コマンドとコマンドハンドラーを使用した新しいビジネス要件への適応
クラシックレイヤードアーキテクチャでは、ドメインは永続性レイヤーに依存します。ドメインを変更する場合は、永続化レイヤーも変更する必要があります。これに対して、六角形アーキテクチャでは、ドメインはソフトウェアの他のモジュールに依存しません。ドメインはアプリケーションのコアであり、他のすべてのモジュール (ポートとアダプター) はドメインモデルによって異なります。ドメインは、依存関係の逆転の原則を使用して、ポートを介して外部と通信します。依存関係の反転の利点は、コードの他の部分を壊すことを恐れることなく、ドメインモデルを自由に変更できることです。ドメインモデルは解決しようとしているビジネス上の問題を反映しているため、変化するビジネス要件に適応するようにドメインモデルを更新することは問題ではありません。
ソフトウェアを開発する場合、懸念の分離は従うべき重要な原則です。この分離を実現するには、わずかに変更されたコマンドパターンを使用できます。これは、オペレーションを完了するために必要なすべての情報がコマンドオブジェクトにカプセル化される動作設計パターンです。これらのオペレーションはコマンドハンドラーによって処理されます。コマンドハンドラーは、コマンドを受信し、ドメインの状態を変更して、呼び出し元にレスポンスを返すメソッドです。同期 APIs や非同期キューなど、さまざまなクライアントを使用してコマンドを実行できます。ドメインに対するオペレーションごとに、コマンドとコマンドハンドラーを使用することをお勧めします。このアプローチに従うことで、既存のビジネスロジックを変更することなく、新しいコマンドとコマンドハンドラーを導入することで、新機能を追加できます。したがって、コマンドパターンを使用すると、新しいビジネス要件に適応しやすくなります。
サービスファサードまたは CQRS パターンを使用したコンポーネントのデカップリング
六角形アーキテクチャでは、プライマリアダプターがクライアントからの受信読み取りおよび書き込みリクエストをドメインに疎結合します。この疎結合を実現するには、サービスファサードパターンを使用するか、コマンドクエリ責任分離 (CQRS) パターンを使用するという 2 つの方法があります。
サービスファサードパターンは、プレゼンテーションレイヤーやマイクロサービスなどのクライアントに対応する前面インターフェイスを提供します。サービスファサードは、クライアントに複数の読み取りおよび書き込みオペレーションを提供します。受信リクエストをドメインに転送し、ドメインから受信したレスポンスをクライアントにマッピングします。サービスファサードの使用は、複数のオペレーションで単一の責任を持つマイクロサービスにとって簡単です。ただし、サービスファサードを使用する場合、単一の責任とオープンクローズの原則に従うことは困難です。単一責任の原則では、各モジュールがソフトウェアの 1 つの機能のみに対して責任を負う必要があると規定されています。オープンクローズの原則では、拡張のためにコードを開き、変更のためにクローズする必要があります。サービスファサードが拡張されると、すべてのオペレーションが 1 つのインターフェイスに収集され、より多くの依存関係がそのインターフェイスにカプセル化され、より多くのデベロッパーが同じファサードの変更を開始します。したがって、開発中にサービスがあまり拡張されないことが明らかな場合にのみ、サービスファサードを使用することをお勧めします。
六角形アーキテクチャでプライマリアダプターを実装するもう 1 つの方法は、クエリとコマンドを使用して読み取りオペレーションと書き込みオペレーションを分離する CQRS パターンを使用することです。前述のように、コマンドはドメインの状態を変更するために必要なすべての情報を含むオブジェクトです。コマンドは、コマンドハンドラーメソッドによって実行されます。一方、クエリはシステムの状態を変更しません。唯一の目的は、データをクライアントに返すことです。CQRS パターンでは、コマンドとクエリは別々のモジュールに実装されます。これは、非同期的に処理されるイベントとしてコマンドを実装でき、API を使用してクエリを同期的に実行できるため、イベント駆動型アーキテクチャに従うプロジェクトに特に便利です。クエリには、最適化された別のデータベースを使用することもできます。CQRS パターンの欠点は、サービスファサードよりも実装に時間がかかることです。長期的にスケーリングして維持する予定のプロジェクトには、CQRS パターンを使用することをお勧めします。コマンドとクエリは、単一責任の原則を適用し、特に大規模なプロジェクトで疎結合ソフトウェアを開発するための効果的なメカニズムを提供します。
CQRS には長期的には大きな利点がありますが、初期投資が必要です。このため、CQRS パターンを使用する前にプロジェクトを慎重に評価することをお勧めします。ただし、読み取り/書き込みオペレーションを分離することなく、最初からコマンドとコマンドハンドラーを使用してアプリケーションを構造化できます。これにより、後でそのアプローチを採用することを決定した場合、CQRS のプロジェクトを簡単にリファクタリングできます。
組織のスケーリング
六角形アーキテクチャ、ドメイン駆動型設計、および (オプションで) CQRS の組み合わせにより、組織は製品を迅速にスケーリングできます。Conway の法則によると、ソフトウェアアーキテクチャは企業のコミュニケーション構造を反映するように進化する傾向があります。この観測には歴史的に否定的な意味があります。これは、大規模な組織がデータベースやエンタープライズサービスバスなどの技術的な専門知識に基づいてチームを編成することがよくあるためです。このアプローチの問題は、製品と機能の開発には常にセキュリティやスケーラビリティなどのクロスカットの懸念が伴い、チーム間の継続的なコミュニケーションが必要であることです。技術的な機能に基づいてチームを構築すると、組織に不要なサイロが発生し、コミュニケーションが悪くなり、所有権が不足し、全体像が見えなくなります。最終的に、これらの組織の問題はソフトウェアアーキテクチャに反映されます。
一方、逆方向コンウェイマヌーバーは、ソフトウェアアーキテクチャを促進するドメインに基づいて組織構造を定義します。例えば、部門横断的なチームには、DDD とイベントストーミングを使用して識別される特定の一連の境界コンテキストに対する責任が与えられます。 https://www.eventstorming.com/これらの境界コンテキストは、製品の非常に具体的な機能を反映している可能性があります。たとえば、アカウントチームが支払いコンテキストを担当する場合があります。各新機能は、緊密に連携し、疎結合された責任を持つ新しいチームに割り当てられるため、その機能の提供のみに集中し、市場投入までの時間を短縮できます。チームは機能の複雑さに応じてスケーリングできるため、複雑な機能をより多くのエンジニアに割り当てることができます。
