3 アーキテクチャ

この章では、Ratpackアプリケーションの概要について説明します。

1.3 強い型付け

Ratpackは強い型付けです。Javaという強い型付けの言語で実装されているだけでなく、そのAPIも型を重視しています。たとえば、Registry という概念がRatpackで広く使用されています。Registryは、型をキーとして使用するマップと考えることができます。

これは、Groovyでアプリケーションを実装しているRatpackユーザーにとって最も関心があるかもしれません。RatpackのGroovyアダプターは、最新のGroovy機能を使用して、慣用的で簡潔なGroovy APIを維持しながら、静的型付けを完全にサポートします。

2.3 ノンブロッキング

Ratpackは、コアとしてイベントベース（つまりノンブロッキング）のHTTP IOエンジンであり、応答ロジックの構築を容易にするAPIです。ノンブロッキングであるということは、APIが非同期である必要があるため、「従来の」ブロッキングJava APIとは異なるスタイルのAPIを必要とします。

Ratpackは、HTTPアプリケーション向けのこのスタイルのプログラミングを大幅に簡素化することを目指しています。非同期コードを構造化するためのサポートを提供し（「非同期とノンブロッキング」の章を参照）、リクエスト処理を自己構築型の非同期的にトラバースされる関数のグラフに構造化するための革新的なアプローチを使用しています（使用するほど複雑に聞こえないほどです）。

3.3 構成要素

次のセクションでは、「引用符」を使用して、Ratpackの主要な用語と概念を示します。

Ratpackアプリケーションは、「起動構成」から始まります。これは、アプリケーションを起動するために必要な構成を提供するものです。Ratpack「サーバー」は、「起動構成」のみから構築および起動できます。「サーバー」は、起動すると、リクエストのリスニングを開始します。この側面の詳細については、「起動」の章を参照してください。

「起動構成」に提供される構成の重要な部分の1つは、「ハンドラーファクトリー」です。これは、「ハンドラー」を作成します。「ハンドラー」は、各リクエストに応答するように求められます。ハンドラーは、次の3つのうちいずれかを行うことができます。

1. リクエストに応答する
2. 「次の」ハンドラーに委任する
3. ハンドラーを「挿入」し、すぐに委任する

すべてのリクエスト処理ロジックは、単にハンドラーの構成です（この側面の詳細については、Handlersの章を参照してください）。重要なのは、処理がスレッドにバインドされておらず、非同期的に完了できることです。「ハンドラー」APIは、この非同期的な構成をサポートしています。

ハンドラーは「コンテキスト」で動作します。「コンテキスト」は、ハンドラーグラフの特定の時点でのリクエスト処理の状態を表します。その重要な機能の1つは、型でオブジェクトを取得するために使用できる「レジストリ」として機能することです。これにより、ハンドラーは公開型によって「コンテキスト」から戦略オブジェクト（通常は主要なインターフェースを実装するオブジェクト）を取得できます。ハンドラーがハンドラーグラフに他のハンドラーを挿入すると、コンテキストレジストリに貢献できます。これにより、ハンドラーはコード（戦略オブジェクトとして）を下流のハンドラーに提供できます。詳細については、「コンテキスト」の章、およびこのコンテキストレジストリが実際にどのように使用されるかについては、次のセクションを参照してください。

これは、Ratpackアプリケーションの抽象的な概要でした。これがすべて実際のコードにどのように変換されるかは、正確には不明かもしれません。このマニュアルの残りの部分と、付属のAPIリファレンスで詳細を提供します。

4.3 Registry を介したプラグインと拡張性

Ratpackにはプラグインの概念はありません。ただし、Google Guiceとの統合アドオンは、Guiceモジュールを介した一種のプラグインシステムを容易にします。Guiceは、依存性注入コンテナです。Guiceモジュールは、依存性注入コンテナの一部となるオブジェクトを定義します。Guiceモジュールは、ハンドラーで使用される主要なRatpackインターフェースの実装を提供することで、プラグインとして機能できます。Guice統合を使用する場合、Guiceに認識されているすべてのオブジェクト（通常はGuiceモジュールを介して）は、「コンテキストレジストリ」を介して取得できます。つまり、ハンドラーはそれらを型で取得できます。

これがなぜ便利なのかを理解するために、オブジェクトをJSONとして応答にレンダリングする要件を使用します。「ハンドラー」に提供される「コンテキスト」オブジェクトには、render(Object) メソッドがあります。このメソッドの実装は、指定された型のオブジェクトをレンダリングできる Renderer の実装をコンテキストレジストリで検索するだけです。Guiceで使用できるオブジェクトはレジストリを通じて使用できるため、レンダリングに使用できます。したがって、目的の型のRenderer実装を使用してGuiceモジュールを追加すると、リクエスト処理に統合できます。これは、単純な依存性注入の概念と変わりません。

上記ではGuice統合を使用しましたが、このアプローチはGuiceに結び付けられていません（GuiceはRatpackのコアAPIの一部ではありません）。別の依存性注入コンテナ（Springなど）を簡単に使用することも、コンテナをまったく使用しないこともできます。オブジェクトの任意のソースをRatpackのRegistryインターフェースに適応させることができます（ビルダーもあります）。

5.3 サービスとビジネスロジック

Ratpackは、リクエスト処理（つまりビジネスロジック）に関連しないコードの構造化方法について、意見を持っていません。「サービス」という用語を、何らかのビジネスロジックを実行するオブジェクトの包括的なものとして使用します。

ハンドラーは、もちろん、必要なサービスを自由に使用できます。ハンドラーからサービスにアクセスするための主なパターンは2つあります。

1. ハンドラーの構築時にサービスを提供する
2. コンテキストレジストリからサービスを取得する