BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

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

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

原文(投稿日: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
 
 

この記事に星をつける

おすすめ度
スタイル

BT