最近、タイムラインが非常に短い統合プロジェクトがありました。すべての統合関連プロセスが一元化されている Biztalk を使用することが要件です。
私のプロジェクトでは、調達システムからの注文が、順番に実行する必要がある複数のタスクになる可能性があるジョブ キュー パターンを使用する必要があります。これは、後で特定のイベントでその注文に対して作成されるタスクが増えるにつれて、より複雑になります。
BizTalk では、再利用可能で、保守が容易で、後で新しい顧客、ターゲット システム、およびトランザクションで使用するためにプラグインできるフレームワークを作成することはできません。代わりに、ジョブの作成と実行が Biztalk から開始される純粋な C# + EF4.1 アプローチを選択しました。
基本的に、Windows サービスの役割を担うように BizTalk を縮小しました。
これはデザインが悪いのでしょうか？これは悪いアプローチですか？私の心はそう言っていますが、私が直面している制約により、これが利用可能な最良のアプローチです.
ただし、最終的には、問題に対処するためのソフトウェア ソリューションを構築しています。たとえそれが規範に従わないことを意味するとしても。
あなたの考えは何ですか？