翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
設計による品質
六角形アーキテクチャを採用することで、プロジェクトの最初からコードベースの品質を高めることができます。開発プロセスを遅らせることなく、期待される品質要件を最初から満たすのに役立つプロセスを構築することが重要です。
ローカライズされた変更と読みやすさの向上
六角形アーキテクチャアプローチを使用すると、デベロッパーは他のクラスやコンポーネントに影響を与えることなく、1 つのクラスやコンポーネントのコードを変更できます。この設計により、開発されたコンポーネントの結合が促進されます。ドメインをアダプターから切り離し、よく知られているインターフェイスを使用することで、コードの読みやすさを高めることができます。問題やコーナーケースを識別しやすくなります。
このアプローチは、開発中のコードレビューを容易にし、未検出の変更や技術的負債の導入を制限します。
最初にビジネスロジックをテストする
ローカルテストは、end-to-end、統合、ユニットテストをプロジェクトに導入することで実現できます。End-to-endのテストは、受信リクエストのライフサイクル全体を対象としています。通常、アプリケーションエントリポイントを呼び出し、ビジネス要件を満たしているかどうかをテストします。各ソフトウェアプロジェクトには、既知の入力を使用し、期待される出力を生成するテストシナリオが少なくとも 1 つ必要です。ただし、各テストはエントリポイント (REST API やキューなど) を介してリクエストを送信するように設定する必要があるため、コーナーケースシナリオを追加すると複雑になる可能性があります。ビジネスアクションに必要なすべての統合ポイントを通過し、結果をアサートします。テストシナリオの環境を設定し、結果をアサートするには、デベロッパーに多くの時間がかかる場合があります。
六角形アーキテクチャでは、ビジネスロジックを個別にテストし、統合テストを使用してセカンダリアダプターをテストします。ビジネスロジックテストでは、模擬アダプターまたはフェイクアダプターを使用できます。また、ビジネスユースケースのテストとドメインモデルのユニットテストを組み合わせて、結合率が低く高いカバレッジを維持することもできます。統合テストではビジネスロジックを検証しないでください。代わりに、セカンダリアダプターが外部サービスを正しく呼び出すことを確認する必要があります。
理想的には、テスト駆動型開発 (TDD) を使用して、開発の開始時に適切なテストでドメインエンティティまたはビジネスユースケースの定義を開始できます。最初にテストを記述すると、ドメインに必要なインターフェイスのモック実装を作成するのに役立ちます。テストが成功し、ドメインロジックルールが満たされたら、実際のアダプターを実装し、ソフトウェアをテスト環境にデプロイできます。この時点では、ドメインロジックの実装が理想的ではない可能性があります。その後、設計パターンを導入するか、コードを一般的に再配置することで、既存のアーキテクチャのリファクタリングに取り組み、それを進化させることができます。このアプローチを使用することで、リグレッションバグの発生を回避し、プロジェクトの拡大に合わせてアーキテクチャを改善できます。このアプローチを継続的な統合プロセスで実行する自動テストと組み合わせることで、本番稼働前に潜在的なバグの数を減らすことができます。
サーバーレスデプロイを使用する場合、手動統合とend-to-endテストのために、 AWS アカウントのアプリケーションのインスタンスをすばやくプロビジョニングできます。これらの実装手順の後、リポジトリにプッシュされる新しい変更をすべて実行してテストを自動化することをお勧めします。
保守性
保守性とは、アプリケーションを運用およびモニタリングして、すべての要件を満たし、システム障害の可能性を最小限に抑えることです。システムを運用可能にするには、将来のトラフィックや運用要件に適応させる必要があります。また、クライアントへの影響を最小限に抑えながら、またはまったく影響を与えずに、利用可能かつ簡単にデプロイできることを確認する必要があります。
システムの現在の状態と履歴状態を理解するには、それを観察可能にする必要があります。これを行うには、システムが期待どおりに動作し、バグを追跡するためにオペレーターが使用できる特定のメトリクス、ログ、トレースを指定します。これらのメカニズムにより、オペレーターはマシンにログインしてコードを読み取ることなく、根本原因の分析を実行することもできます。
六角形アーキテクチャは、ウェブアプリケーションの保守性を高め、コード全体の作業を減らすことを目的としています。モジュールを分離し、変更をローカライズし、アプリケーションのビジネスロジックをアダプター実装から切り離すことで、オペレーターがシステムをより深く理解し、プライマリアダプターまたはセカンダリアダプターに加えられた特定の変更の範囲を理解するのに役立つメトリクスとログを生成できます。