アプリケーション要件の紹介
今回は各種のイベント、コンサート、演劇、スポーツイベントなどのチケットをオンラインで購入できるアプリケーションを考えます。
通常よく用いられるチケット販売方式には先着と抽選がありますが、1つの記事の中で両方の設計を扱うのは記述量が多くなりすぎるので、チケットの先着販売のみを扱うことにします。チケットの先着販売はチケット在庫などの状態管理を含み、さらに同時に複数の購入者からのリクエストを排他制御しつつ処理する必要があるため、アクターのメリットを生かせる題材です。
多種多様なイベントを扱うチケット販売アプリケーションの場合、ユーザーの行動は大まかに、イベントを探す、イベントの詳細を確認する、チケットを選択する、内容確認の後チケットを購入するという流れになります。
アクターモデルにとって状態管理は重要なので、この中で状態管理が関係する部分を探してみましょう。まずチケット選択画面で販売期間前、販売期間終了、あるいは売り切れといった状態を表示する必要がありますし、チケット在庫数も管理すべき状態です。さらに購入回数制限があるチケットは、過去の購入履歴を状態として管理し、それをもとに次に来る購入リクエストに対して販売を許可・拒否します。
アクターモデルによる設計
要件がわかったところで設計に移ります。アプリケーション設計に慣れている開発者なら、ここでUI、Web API層、アプリケーション層、データベース層という構成を考えて設計を始めたくなるかもしれません。しかしアクターモデルによる設計ではそれらを忘れ、アクターのみに集中して、アクター同士がメッセージを送り合う形でアプリケーションを設計します。この辺りの理由やメリットに関しては前回記事をご参照ください。慣れない設計方法かもしれませんが、ぜひこの新しい設計手法を身につけていただければと思います。Web APIとの接続はこの記事の後半で、データベースとの接続は次回の記事で解説します。
ではアクターモデルによるアプリケーション設計とは具体的にどう進めるのか？ というと、以下の3種類の図を用いて設計を行うとよいでしょう。
- シーケンス図
- 状態遷移図
- 樹形図
Akkaを用いると、これらの図による設計を素直にソースコードに落とし込めます。言い換えるとソースコードを書き始める前に適切な設計を行う能力が求められます。
まずは登場するアクターの種類を考えます。購入者アクターとチケット在庫管理アクター、そしてイベントアクターを考えましょう。イベントアクターはチケット在庫管理アクターの親となるアクターです。これらのアクターの詳しい親子関係については、後ほど樹形図を用いて改めて説明します。
次に、シーケンス図を使ってチケット購入の流れをアクター同士のメッセージのやりとりとして表現します。以下の図のように、チケット購入の処理は、チケット購入者アクターがメッセージを受けて、イベントアクターを経由してチケット在庫管理アクターにメッセージを送り、そこから最初の送信元にメッセージを送り返す流れで処理されます。最初のメッセージ送信元は、Web APIなどアクターの外部からの入力となりますが、今は外部からの入力は考えず、アクターがメッセージを受け取った後の処理だけを意識してください。
チケット販売開始と販売終了の処理はいずれも以下のシーケンス図で表される流れになります。チケット在庫管理アクターはチケット販売開始メッセージを受け取って初めてチケット購入リクエストを受け付けることができます。またチケット販売期間終了を示すメッセージを受け取ったら内部状態を変化させ、在庫が余っていてもそれ以降のチケット購入リクエストを拒否します。
アクターの状態を設計するためには状態遷移図を用います。チケット購入者アクターには活性／非活性という、2つの状態があり、会員登録直後は非活性状態、クレジットカード情報などチケット購入に必要な個人情報が全て登録されたら活性状態となります。
チケット在庫アクターはチケット購入者アクターに比べて少し複雑です。最初は販売開始前の状態で、次にチケット販売開始状態になり、購入リクエストを受け取るたび在庫数を減らします。そして在庫数がなくなると売り切れ状態に遷移します。また、在庫数が余っていても販売期間終了メッセージを受け取ると販売終了状態に遷移します。
最後に、Akkaアクターは全てガーディアンアクターを頂点とする親子関係の中に存在するので、樹形図によってそれを表現します。下図の頂点がガーディアンアクターで、その下にチケット購入者の親アクターとイベントの親アクターが配置されます。イベント親アクターの下にはイベントアクターが、さらにイベントアクターの下にはチケット在庫管理アクターがあります。
