ワークフローエンジンを使用する場合

私は過去にいくつかのワークフローエンジンでプログラマーとして働いてきましたが、なぜワークフローエンジンを最初に選んだのかについて明確にすることはありませんでした。そして、プログラマーとして、コードを書いているときに何かをする方法が少なくとも100あることを知っていますが、最良の方法はごくわずかです！

優れたDI対応アプリケーションを設計することよりも、どのユースケースがワークフローエンジン（またはその概念）によって最もよく解決されるかはまだわかりません。ワークフローエンジンが最適なオプションの1つである、ドメインに中立なユースケースの一般的な特性を探しています。

私の質問は次のとおりです。要件の一般的な特性は、優れたワークフローエンジンを選択し、その周りにコーディングするためのシグナルと見なすことができますか？

ワークフローエンジンは、最初から最後まで移動する必要があるが、そこに到達するためのさまざまなパス/ロジック/ルールがある場合に役立ちます。

たとえば、コンテンツを公開するプログラムを書いたとしましょう。そのため、私の場合、公開はレビュープロセス、法的手続き、そして最終承認を経て行われます。プロセスロジックとステップを実装するプログラムを作成します。今、これは私と私の会社にとって素晴らしい仕事です。だから、私は他の人が私のプログラムを使うべきだと決めました。

残念ながら、誰もが同じプロセスを使用してコンテンツを公開するわけではないため、異なるケースごとに個別のプロセスを作成する代わりに、ワークフロープロセスを実装して、プログラムがすべてのユーザーに対応できるようにします。これらの2つのポイントの間にいくつのステップ、ルール、またはロジックがあっても、結果は同じです。

そのため、最初から最後まで変化するプロセスがある場合は、ワークフローを使用します。同じプロセスを全員が使用できる場合、ワークフローは必要ありません。

あなたがユースケースを要求したことは知っていますが、考えられるすべてのユースケースを想像するよりも利点をリストする方が簡単です。もちろん、比較するエンジンと言語によって利点は異なりますが、一般的には：

1. ルールをコードではなくデータとして保持することは、再コンパイルする必要がないことを意味します。そのため、変更をすばやくテストしたり、実行時に変更したりすることができます。

2. ユーザーはより合理的にルールを編集することが期待されます。プログラマーにコードを書いてもらえないような方法で、インタラクティブにいじくり回す可能性があります。

3. ルールをデータとして保持することにより、データを視覚化および変更するツールを作成できます。

4. ルールをデータとして保持することで、メタプログラミングがより簡単になります。データを分析し、コードでは非常に難しい複雑な方法でさらに挿入するコードを作成できます。

これらのすべては、コードで直接行うことができます（たとえば、特定のタイプのすべてのルールを見つけるC＃パーサーを記述し、より多くのルールのコードを生成し、アセンブリのアンロードを許可する方法でアセンブリに動的に挿入し、ユーザーはビジュアライザーとエディターを使用してこれを行うこともできます）が、言語によってははるかに難しい場合があります（Lispを使用するプログラマーは項目1〜4を「プログラミング」と呼ぶ場合があります）。

この種のことを使用する必要があるのは、あまり価値のないユーザーが設定できる場合だけです。ツールを提供して問題を解決できる場合は、他の重要な作業に戻って使用します。

あなたがまだ彼らのためにそれを設定する必要があるなら、私はあなたがあなたが使い慣れたツールで同じ結果を得る10の異なる方法を考えることができると想像するでしょう。

これは古い質問のように見えますが、実際には何度も表面化しています。ジョンの答えに同意します。次のシナリオでは、ワークフローエンジンの生産性が高いことがわかりました。

1. ソフトウェアを通して表現/実装しようとしている基礎となるビジネスプロセスがあります。
2. プロセスのすべてまたは一部の段階で作業する単一の（おそらく複合）ビジネスエンティティがあります。Jonが与えた例では、このエンティティまたはワークフローアイテムはコンテンツまたは記事になります。ワークフローの別の例としてバグ追跡を検討してください。バグは、ユーザーが行うアクションに基づいて、さまざまな状態間で遷移します。
3. ワークフローを使用してプロセスをモデル化します。ビジネスプロセスが変化すると予想される場合にのみ、変更によって、ユーザーのアクションまたは遷移の結果として実行されるシーケンスまたはアクションを意味します。

問題のドメイン/要件にビジネスプロセスがあるかどうかを確認するために、非常に注意して重要です。ワークフローに「適合」させないでください。

ワークフローエンジンの提案に使用するガイドラインがいくつかあります。

1）ビジネスアナリストがコーディングの背景を持っていないが、図を描くことができる場合。

最新のワークフローエンジンは、ビジネスプロセスモデリング表記法、またはSharePointおよび同様のシステムで利用可能な機能の少ないバージョンを使用します。これらにより、技術的に有能でありながらコーディングが困難なチームのメンバーは、多くのワークフローを設計および開発できます。

2）作業の進行状況を監視する必要がある場合は、エスカレーションを実行し、コンピューター制御プロセスと人間制御プロセスの間を行ったり来たりします。

監視と自己参照は、最新のワークフローエンジンの特徴です。

HRビジネスの観点から見ると、ワークフローエンジンは非常に重要です。

1. それらは毎回同じであっても、構造化されたプロセスを提供します。

2. 透明性を提供します

   • 誰が変更をリクエストしたか、
   • いつリクエストされたか、
   • 誰が承認したかなど

   この透明性は、プロセスの推進と所有権の促進に役立ちます。

フォームが統合され、インテリジェントで、ビジネスロジックをサポートしていると仮定すると、タイムライン、処理効率、データ品質にも劇的な影響を及ぼします。セキュリティも考慮事項であり、機密情報を安全なシステムに含めることは、署名を待っている紙のフォームを持ち歩くよりもはるかに望ましいことです。また、はるかにモバイルです。最近の実装の後、あるマネージャーは、彼が旅行するたびに署名のために物事を彼に投稿するのを手間を省くと言った。

HRを代表して：長いライブワークフロー!!!