Domain Modeling Made Functional › Modeling Workflows as Pipelines

TL;DR

• ビジネスプロセスを、一連のドキュメントの変換として捉え、パイプラインとしてモデリングする。
• パイプラインは小さなステップの集まりで、各ステップは 1 つのものだけを変換する。各ステップはステートレスで副作用を持たない。

内容

目標

この章では、ワークフローを型でモデリングする。目標は第5章 Domain Modeling with Typesと同じで、ドメインエキスパートが読めるものを作ることである。

例として、第2章で文書化した「注文確定」ワークフローを取り上げる。

bounded context: Order-Taking
 
workflow: "Place order" =
  input: UnvalidatedOrder
  output (on successs):
    OrderAcknowledgmentSent
    AND OrderPlaced (to send to shipping)
    AND BillableOrderPlaced (to send to billing)
  output (on error):
    ValidationError
 
  // ステップ 1
  do ValidateOrder
  If order is invalid then:
    return with ValidationError
 
  // ステップ 2
  do PriceOrder
 
  // ステップ 3
  do SendAcknowledgmentToCustomer
 
  // ステップ 4
  create and return the events

パイプラインとしてのワークフロー

多くのビジネスプロセスは、一連のドキュメントの変換として考えられる。本書では、ビジネスプロセスをパイプラインで表し、それをさらに小さなパイプの集まりとして表現する。各パイプは 1 つのものだけを変換する。このようなプログラミングスタイルは、変換指向プログラミングとも呼ばれる。

関数型プログラミングの原則に従い、パイプラインの各ステップはステートレスで副作用がないようにする。こうすると、各ステップを独立してテストし、理解できる。

節の構成

• ワークフローの入力
• 状態のモデリング
  • 状態の集合による注文のモデリング
  • ステートマシン
• ワークフローのモデリング
  • 型を使ったワークフローの各ステップのモデリング
  • エフェクトの文書化
  • ステップからワークフローを合成する
  • 依存関係をパラメータに含めるか
  • 長時間稼働するワークフロー

型の置き場所

この章で作る型は、公開 API で使う型と、内部のステップで使う型とで、ファイルを分けるのがよい。

• 公開 API（DomainApi.fsx）: 入力（データとコマンド）、出力（イベントとエラー）、ワークフロー関数自身の型
• 内部のステップ（PlaceOrderWorkflow.fsx）: 各ステップの型定義

キーワード

• ワークフロー
• ビジネスプロセス
• ドメインエキスパート
• 関数型プログラミング
• 副作用

自分の理解

日本語話者の場合、ドメインエキスパートが読めるものにするには、ドメインに日本語を使うことも考えたい。