アプリケーションのビジネスロジック層にフロー制御を行うフレームワークを使っていくことが重要だと思っていますが、BPELやBPMの概念とかぶっていて、うまく説明できませんでした。最近、マイクロフローをいう言葉を知ったのですが、このマイクロフローの導入について、多くのアプリケーションで検討が必要です。
Webのプレゼンテーションにフロー制御を、というのはSpring Web FlowやSeamを初め、主流になってきている考え方です。こうしたフロー制御フレームワークは、MVCに加えて画面間の遷移についても制御を追加します。
歴史的に見ればコンポーネント化が進んできているということです。処理の「そのもの」「起動制御」「流れ」の分離と捉えることが出来ます。コンポーネントの「再利用」の夢は消えて久しいですが、それでもコンポーネント化が重要なのは保守性向上と分業化推進として捉えられます。DIや単体テスト技術の向上で、以前に比べて細かい粒度で的確なコンポーネント化が可能になってきたことも後押しになっています。
さて、この流れで捉えれば、ビジネスロジックでもコンポーネント化の推進のためにフロー制御化は非常に重要です。これを可能にするのがマイクロフローという概念です。
マイクロフローの対になる概念がマクロフローで、これはビジネスプロセスと呼ばれているものです。ロングタームトランザクションと呼ばれたりもしますが、処理が複数のサービスをまたがっていたり処理待ちのために保留が可能であったりします。代表的なのは誰かの承認がないと継続されないと言ったワークフロー制御のことです。SOAで語られるBPELやBPM、CRMとかSFAでいわれるようなワークフローもマクロフローと捉えることができます。
これに対してマクロフローとは、ショートタームで完結するもので、人が介在せず、コンポーネントをアセンブルしたものです。パイプラインやフィルターのようなパターンは代表的なマクロフローと言えます。
どちらも「フローを使って、コンポーネントやサービスを統合する」という意味では同じ文脈なので混同されやすいですが、粒度や求められる機能がだいぶ違います。
A survey of patterns for Service-Oriented Architectures (Uwe Zdun, Carsten Hentrich, Wil M.P. Van Der Aalst 2006)では、7.2 Integrating services and processesの章で、
In order to create the link between an activity of a process and a service, integration logic is required (represented by a process flow). We classify this type of integration logic as process integration logic. For this reason, we distinguish between two general types of process flow: macroflow representing the higher-level business process, and microflow addressing the process flow within a macroflow activity. The distinction between micro- and macroflow is a conceptual decision, in order to be able to design process steps at the right level of granularity when designing at the long running business process level (macroflow) or the short running, more technical level (microflow). This conceptual decision is, thus, important for separating the business problems from the more technical/application problem space.プロセスのアクティビティとサービスのリンクを作成するに辺り、統合するためのロジックが必要となります（プロセスフロー）。我々はプロセスインテグレーションロジックとして、統合ロジックを分類します。これにより以下の2つのタイプのフローを区別します。マクロフロー：高レベルなビジネスフロー。マイクロフロー：マクロフローのアクティビティの中のプロセスフローとして位置づけ。これらマクロフローとミクロフローの区分は概念的なもので、長期間実行されるビジネスプロセスレベル（マクロフロー）と、短期で技術視点のレベル（マイクロフロー）の粒度を正しく設計するために必要となります。この区分はビジネス視点の問題領域を技術的/アプリケーション視点の問題領域から切り離すために非常に重要です。
マイクロフローの導入が特に効果的なのは、小さなルールや手順を積み重ねて処理を行うようなデータ抽出や加工を行う場合です。逆に言うと、ビジネスロジックの設計に当たって、小さなルールや手順を積み重ねていけるように表現することが重要です。マイクロフローの導入は単体テスト性の向上とともに、設計と実装のリンクを強めることで解析性（どこに何が書かれているのか）が向上するなど、保守性に必ず貢献します。
ただ、シンプルであるがために、使いやすいOSSフレームワークが存在しないともいえます。とはいえ、そんなに難しいわけではないので作ってもよいと思います。課題になるのは変数のスコープ制御、エラー処理、スレッド処理ぐらいでしょうか。きちんと設計時点でモデリングができれば作りやすいと思います。
ところで、こうした議論をしていると、エンジニアのスキルや視点が、「コンポーネントを作る人」、「アプリとして組み上げる人」、「アプリをつないでシステムとして管理する人」と分かれてきていると感じます。
これらの分離は「アーキテクチャ」として、アプリケーション設計前の段階でコンセプトとして決定されるべきモノです。もちろん、その後の設計プロセスやプロジェクトマネージメントにも大きな影響を与えます。
アプリケーションを作ることはコーディングとは違うレベルの概念になりました。コーディングという作業に落ちる前に、アプリケーションを、どのようにコンポーネントの集合として表現するのか。アーキテクトの役割は、ここにあるといえます。
