TL;DR
- 関数型のアーキテクチャでは、ワークフローを 1 つの関数として扱う。入力はコマンドオブジェクト、出力はイベントオブジェクトのリストである。
- ワークフローは常に 1 つの境界づけられたコンテキストの中に収まる。コンテキストの内部では、隠れた依存関係を生むドメインイベントを避ける。
内容
ワークフローを関数として扱う
ビジネスイベントを通じてドメインを理解するでは、ワークフローを「1 つ以上のドメインイベントを生成する、コマンドによって始まる小さなプロセス」として扱った。関数型のアーキテクチャでは、ワークフローは 1 つの関数に対応する。入力はコマンドオブジェクトで、出力はイベントオブジェクトのリストである。
設計を図にするときは、ワークフローを入力と出力を持つ小さなパイプとして描く。境界の外からトリガーされるワークフロー（公開ワークフロー）は、境界から少しはみ出すように描く。
ワークフローは常に 1 つの境界づけられたコンテキストの中に収まる。複数のコンテキストをまたいでエンドツーエンドのシナリオを実装することはない。ワークフローのモデリングは第7章 Modeling Workflows as Pipelinesで扱う。
コンテキストの内部ではドメインイベントを避ける
オブジェクト指向プログラミングでは、コンテキストの内部で発生するドメインイベントを持つことが一般的である。たとえば、ワークフローのオブジェクトが OrderPlaced イベントを発生させ、あるハンドラがそれを受け取って注文の確認書を送り、別のハンドラが BillableOrderPlaced イベントを生成する。
しかし、この方法では隠れた依存関係が生まれるので、関数型のアーキテクチャでは避ける。可変な状態を持つグローバルなイベントマネージャもないので、理解しやすく保守しやすい。