BT

新しい あなたは、アーリーアダプター?それともイノベーター?そんな皆様に、InfoQの新機能をご案内しています。詳細はこちら

イベントベースのシステムにおけるプロセスマネージャー

| 作者: Jan Stenberg フォローする 5 人のフォロワー , 翻訳者 笠原 王徳  人のフォロワー 投稿日 2017年8月3日. 推定読書時間: 1分未満 |

原文(投稿日:2017/07/28)へのリンク

ドメインが保持する変更を通知するためにイベントを発行することは、異なるドメイン同士を互いから疎結合に保つが、そこに本当にイベントの論理フローが存在するのであれば、フローは暗黙的なものとなり追跡するのが難しくなってしまう。より良い解法はプロセスマネージャーパターンを用いてプロセスの全てを追跡し続けることである、とBernd Rucker氏は今年のDDD eXchange conferenceにおける、長期実行プロセスとドメイン駆動設計 (DDD)に関する彼の発表の中で述べた。

長期実行プロセスに関して10年以上の業務経験を持ち、Camundaの共同創業者であるRucker氏は、顧客観点では、オンラインストアで何かを購入するプロセスは本当に単純であると発言した。注文し、支払いを行い、出荷されたものを受け取るだけである。この行為をDDDの観点で実装すると、例えば店舗・支払い・在庫・発送という4つのビジネス能力とこれらに対応した境界づけられたコンテキストが得られる。これらのコンテキストは購入プロセスと調和してドメインイベントを送信することが可能である。注文が確定した、支払いを受信した、商品のピッキングが完了した、商品を出荷した、などである。

注文プロセスを満足するために、コンテキストは協調してイベントが送信されたことに反応する必要がある。注文確定イベントが送信されたとき、支払いコンテキストはこれらのイベントをサブスクライブしており、支払い完了イベントが送信される前に注文のための金銭を収集することになる。しかし、このことに関する1つの問題は、支払いコンテキストは注文確定イベントに加え、支払いの契機となる全ての他のイベントに注意を払う必要がある。実際、これは新しいクライアントが支払いを必要とした時はいつでも、この支払いコンテキストが影響を被ることを意味する。

Rucker氏は、この手法が結合度を低く抑えはするが、プロセスの概念が存在しないことがイベントフローに関わる問題であると述べた。このことにより全体の論理フローを見通すことが困難となる。彼はMartin Fowler氏を引用した。もう1つの欠点は、イベントフローの変更を引き起こす新しい事業上の要件、例えばVIP顧客は請求書により注文ができる、は複数のコンテキストの変更を必要とする可能性がある。

Ruckerによると、より良い解法はプロセス全体の追跡を1箇所で行うこと、以下の主な責務を持つプロセスマネージャーパターンを用いることである。

  • イベントをコマンドに変換する。注文確定イベントは過去に発生した何らかの概念であり、それは発生することを本当に期待する何らかをものを示すコマンド、この例では支払いを回収するコマンドの存在を暗に示している。
  • フローをドメインロジックの一級市民として実装する。全体フローは個々のステップ内のロジックと同様に、このコンテキスト内のドメインロジックの一部である。
  • 長期実行フローのための状態を制御する。

実装ビューでは、Ruckerによると最も挑戦的なのは状態制御である。実装の方法は以下を含む。

  • アクターモデルを用いて実装する。あるアクターが局所的な状態を持ちうる部分は、例えばAkkaを使用する。1つのアクターがプロセスマネージャーとして動作し、フロー全体に対して責任を持つ。これはVaughn Vernon氏の書籍であるReactive Messaging Patterns with the Actor Modelにも記述されている。
  • あるエンティティにプロセスフローの状態を保持する。これはRucker氏の経験上最もよく用いられる実装方法である。
  • 全ての必要なステップがメッセージと共に送信されるRouting slipパターンを用いる。これによりプロセスの状態を中央ストレージで管理する必要性を避けることができる。
  • 各ステップが定義された状態機械を用いる。Rucker氏は、状態機械を用いる1つの利点はプロセス状態の可視性であると述べている。

顧客と協働して長期実行プロセスを実装した彼の経験から、Rucker氏はいくつかの犯しがちな誤りを見出した。これには、全くワークフローエンジンを用いない、もしくはお手製もの、そしてコード記述の必要がないとされる製品を使用することが含まれる。代わりに、彼はオープンソースで軽量なフレームワークライブラリを使用することを推奨している。これらの1つにはCamundaが含まれ、これはユーザーのコードに組み込むことができる。彼は最も良く用いられるケースのみを実装し、ほとんどの例外ケースを除外することも勧めている。おおよそ全てのケースの99%に気を配り、残りを人間が介入することにするというのはGreg Young氏も推奨している。

Rucker氏は、彼の発表内容を用いた単純な注文システムを実装したGitHub上の例を公開している。

来年のDDD eXchange Conferenceは、ロンドンで2018年4月26日から27日にかけて開催される計画である。

 
 

Rate this Article

Adoption Stage
Style
 
 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT