8
ワークフローするかしないか？
私は、軽量保険金請求システムの開発を開始しようとしている開発者チームの責任者です。システムには多くの手動タスクとビジネスワークフローが含まれており、Windowsワークフロー（.NET 4.0）の使用を検討しています。 ビジネスドメインの例は次のとおりです。保険契約者は、コンタクトセンターに電話して、申し立てを提出します。この「イベント」は、手動で並行して実行される2つのサブタスクを起動し、完了するまでに長い時間がかかる場合があります。 顧客の不正をチェック–オペレーターが手動でさまざまなクレジット会社に電話をかけ、不正な顧客の可能性をチェックして評価します。ここから、サブタスクはいくつかのサブステータス（進行中のチェック、参照チェックの失敗、参照チェックの合格など）を入力できます。 修理センターへのアイテムの送信–保険契約者が申し立てを提出したアイテムが修理センターに送られ、修理される手動プロセス。ここから、サブタスクはいくつかのサブステータス（修復待ち、進行中、修復済み、投稿済みなど）を入力できます。クレームは、各サブタスクのステータスが事前定義されたステータス（ビジネスルールに基づく）に達した場合にのみ続行できます。 表面的には、ワークフローは確かに最良のテクノロジーの選択のようです。しかし、私はWF 4.0の使用に関していくつかの懸念を持っています。 スキルセット–平均的な開発者スキルセットを見ると、ワークフローを理解または知っている開発者はあまり見かけません。 保守性– WF 4.0プロジェクトに対するコミュニティ内のサポートはほとんどないようで、スキルセットの欠如と相まって、保守性に関する懸念が生じています。 参入障壁–私は、Windowsワークフローの学習曲線が急であり、必ずしも簡単に習得できるとは限らないと感じています。 新製品–ワークフローが.NET 4.0用に完全に書き直されたので、私はこの製品を第1世代の製品と見なしており、必要な安定性がない可能性があります。 評判–以前のバージョンのワークフローは十分に評価されておらず、開発が困難であると考えられ、ビジネスへの関心が低かった。 私の質問は、この状況ではWindowsワークフロー（WF）4.0を使用する必要があるか、それとも代替テクノロジー（Simple State Machineなど）を使用するか、それともより優れたワークフローエンジンを使用するかということです。