BPM スタイルの統合

こんにちは、 ハブル!

当社は ERP クラスのソフトウェア ソリューションの開発を専門としています。その大部分は、膨大な量のビジネス ロジックと EDMS によるドキュメント フローを備えたトランザクション システムによって占められています。 当社製品の現在のバージョンは JavaEE テクノロジーに基づいていますが、マイクロサービスの実験も積極的に行っています。 このようなソリューションの最も問題のある領域の XNUMX つは、隣接するドメインに属するさまざまなサブシステムの統合です。 使用するアーキテクチャ スタイル、テクノロジ スタック、フレームワークに関係なく、統合の問題は常に私たちに大きな頭痛の種を与えてきましたが、最近ではそのような問題の解決に進歩が見られます。

今回ご紹介する記事では、NPO法人クリスタが指定地域で行った経験と建築研究についてお話します。 また、アプリケーション開発者の観点から統合問題に対する簡単な解決策の例を見て、このシンプルさの背後に何が隠されているかを見つけていきます。

免責事項

この記事で説明されているアーキテクチャ上および技術的なソリューションは、特定のタスクのコンテキストにおける個人的な経験に基づいて私によって提案されたものです。 これらのソリューションは普遍的であるとは主張しておらず、他の使用条件下では最適ではない可能性があります。

BPM はそれと何の関係があるのでしょうか?

この質問に答えるには、ソリューションに適用される問題の詳細をもう少し深く掘り下げる必要があります。 一般的なトランザクション システムのビジネス ロジックの主要部分は、ユーザー インターフェイスを介してデータベースにデータを入力し、このデータを手動および自動で検証し、ワークフローを通じて実行し、別のシステム/分析データベース/アーカイブに公開し、レポートを生成することです。 。 したがって、顧客にとってのシステムの重要な機能は、内部ビジネス プロセスの自動化です。

便宜上、通信では「ドキュメント」という用語を、特定のワークフローを「リンク」できる共通のキーによって結合された一連のデータを抽象化したものとして使用します。
しかし、統合ロジックについてはどうでしょうか? 結局のところ、統合タスクはシステムのアーキテクチャによって生成され、顧客の要求によるものではなく、まったく異なる要因の影響下で部分に「分割」されます。

• コンウェイの法則の対象となる。
• 以前に他の製品用に開発されたサブシステムを再利用した結果。
• 非機能要件に基づいて、アーキテクトの裁量で決定されます。

統合アーティファクトでビジネス ロジックが汚染されないようにして、アプリケーション開発者がシステムのアーキテクチャ ランドスケープの機能を詳しく調べる必要がなくなるように、統合ロジックをメイン ワークフローのビジネス ロジックから分離したいという大きな誘惑があります。 このアプローチには多くの利点がありますが、実践してみると効果がないことがわかります。

• メイン ワークフローの実装には拡張ポイントが限られているため、統合の問題を解決するには、通常、同期呼び出しの形式で最も単純なオプションに戻ります (同期統合の欠点については後述します)。
• 別のサブシステムからのフィードバックが必要な場合でも、統合アーティファクトはコア ビジネス ロジックに侵入します。
• アプリケーション開発者は統合を無視し、ワークフローを変更することで簡単に統合を破壊できます。
• ユーザーの観点からシステムは単一の全体ではなくなり、サブシステム間の「継ぎ目」が目立つようになり、冗長なユーザー操作が発生して、あるサブシステムから別のサブシステムへのデータ転送が開始されます。

もう XNUMX つのアプローチは、統合インタラクションをコア ビジネス ロジックおよびワークフローの不可欠な部分として考慮することです。 アプリケーション開発者の資格が急増するのを防ぐために、新しい統合インタラクションの作成は、ソリューションを選択する機会を最小限に抑え、簡単かつ楽に行う必要があります。 これは、思っているよりも難しいことです。ツールは、ユーザーが「足を撃たれる」ことなく、その使用に必要なさまざまなオプションを提供できるほど強力でなければなりません。 トランザクション境界、一貫性、アトミック性、セキュリティ、スケーリング、負荷とリソースの分散、ルーティング、マーシャリング、アプリケーション開発者には、そのようなすべての質問に対する答えがすでに隠されている、かなりシンプルなソリューション テンプレートを提供する必要があります。 これらのテンプレートは非常に安全である必要があります。ビジネス ロジックは非常に頻繁に変更されるため、エラーが発生するリスクが増加します。エラーのコストはかなり低いレベルに維持される必要があります。

しかし、BPM はそれと何の関係があるのでしょうか? ワークフローを実装するには多くのオプションがあります...
実際、当社のソリューションでは、状態遷移図の宣言的定義と遷移用のビジネス ロジックとハンドラーの接続を介したビジネス プロセスの別の実装が非常に人気があります。 この場合、ビジネスプロセスにおける「文書」の現在の位置を決定する状態は、「文書」自体の属性となります。

プロジェクト開始時のプロセスは次のようになります

この実装の人気は、線形ビジネス プロセスの作成が比較的簡単で迅速であるためです。 しかし、ソフトウェア システムが継続的に複雑になるにつれて、ビジネス プロセスの自動化された部分が拡大し、より複雑になります。 プロセスの一部を分解して再利用するだけでなく、各分岐が並行して実行されるようにプロセスを分岐する必要もあります。 このような状況では、ツールは不便になり、状態遷移図の情報内容が失われます (統合の相互作用が図にまったく反映されません)。

要件の明確化を数回繰り返した後のプロセスは次のようになります。

この状況を打開する方法はエンジンの統合でした jBPM 最も複雑なビジネスプロセスを伴う一部の製品に適用されます。 短期的には、このソリューションはある程度の成功を収めました。かなり有益で関連性のある表記法図を維持しながら、複雑なビジネス プロセスを実装することが可能になりました。 BPMN2.

複雑なビジネスプロセスのほんの一部

長期的には、このソリューションは期待に応えられませんでした。ビジュアル ツールを使用してビジネス プロセスを作成する際の労働集約度が高いため、許容可能な生産性指標を達成できず、ツール自体が開発者の間で最も嫌われるツールの XNUMX つになりました。 エンジンの内部構造に関する苦情もあり、多くの「パッチ」や「松葉杖」が出現しました。

jBPM を使用することの主なポジティブな側面は、ビジネス プロセス インスタンス独自の永続的な状態を持つことのメリットとデメリットを認識できるようになったことでした。 また、プロセス アプローチを使用して、信号やメッセージを介した非同期対話を使用して、異なるアプリケーション間の複雑な統合プロトコルを実装できる可能性も確認しました。 これには、永続的な状態の存在が重要な役割を果たします。

上記に基づいて、次のように結論付けることができます。 BPM スタイルのプロセス アプローチにより、幅広いタスクを解決して、ますます複雑化するビジネス プロセスを自動化し、統合アクティビティをこれらのプロセスに調和して適合させ、実装されたプロセスを適切な表記法で視覚的に表示する機能を維持することができます。

統合パターンとしての同期呼び出しの欠点

同期統合とは、最も単純なブロッキング呼び出しを指します。 XNUMX つのサブシステムはサーバー側として機能し、必要なメソッドを使用して API を公開します。 別のサブシステムがクライアント側として機能し、適切なタイミングで呼び出しを行って結果を待ちます。 システム アーキテクチャに応じて、クライアント側とサーバー側は同じアプリケーションおよびプロセスに配置することも、異なるアプリケーションおよびプロセスに配置することもできます。 XNUMX 番目のケースでは、RPC 実装を適用し、パラメータと呼び出し結果のマーシャリングを提供する必要があります。

この統合パターンにはかなり多くの欠点がありますが、その単純さのため実際には非常に広く使用されています。 実装の速さに魅了され、差し迫った締め切りに直面して何度も何度も使用せざるを得なくなり、ソリューションが技術的負債として記録されます。 しかし、経験の浅い開発者が、単に悪影響に気づいていないだけで、無意識にそれを使用してしまうことも起こります。

サブシステムの接続性の最も明らかな増加に加えて、トランザクションの「拡大」および「拡張」に関するそれほど明らかではない問題もあります。 実際、ビジネス ロジックに何らかの変更が加えられた場合、トランザクションは回避できず、その結果、トランザクションは、これらの変更の影響を受ける特定のアプリケーション リソースをブロックします。 つまり、一方のサブシステムが他方のサブシステムからの応答を待つまで、トランザクションを完了してロックを解除することはできません。 これにより、さまざまな影響が生じるリスクが大幅に増加します。

• システムの応答性が失われ、ユーザーはリクエストに対する応答を長時間待つことになります。
• 通常、サーバーはスレッド プールが過密であるためにユーザー リクエストへの応答を停止します。スレッドの大部分は、トランザクションによって占有されているリソースにロックされています。
• デッドロックが発生し始めます。デッドロックが発生する可能性は、トランザクションの期間、トランザクションに含まれるビジネス ロジックおよびロックの量に大きく依存します。
• トランザクションタイムアウトエラーが表示されます。
• タスクで大量のデータの処理と変更が必要な場合、サーバーは OutOfMemory で「失敗」します。また、同期統合の存在により、処理を「軽い」トランザクションに分割することが非常に困難になります。

アーキテクチャの観点から見ると、統合中にブロック呼び出しを使用すると、個々のサブシステムの品質に対する制御が失われます。あるサブシステムの目標品質指標を、別のサブシステムの品質指標から切り離して確保することは不可能です。 サブシステムが異なるチームによって開発されている場合、これは大きな問題になります。

統合されているサブシステムが異なるアプリケーションにあり、両方の側で同期的な変更を行う必要がある場合、状況はさらに興味深いものになります。 これらの変更のトランザクション性を確保するにはどうすればよいでしょうか?

変更が個別のトランザクションで行われる場合は、信頼性の高い例外処理と補償を提供する必要があり、これにより、同期統合の主な利点であるシンプルさが完全に失われます。

分散トランザクションも思い浮かびますが、信頼性を確保するのが難しいため、私たちのソリューションでは分散トランザクションを使用しません。

トランザクション問題の解決策としての「Saga」

マイクロサービスの人気が高まるにつれ、 サーガパターン.

このパターンは、前述の長いトランザクションの問題を完全に解決し、ビジネス ロジックの側からシステムの状態を管理する機能も拡張します。トランザクションが失敗した後の補償は、システムを元の状態にロールバックすることはできませんが、次のような機能を提供します。代替のデータ処理ルート。 これにより、プロセスを「良好な」終了にしようとするときに、正常に完了したデータ処理ステップを繰り返すことを避けることもできます。

興味深いことに、モノリシック システムでは、このパターンは疎結合サブシステムの統合にも関連しており、長時間実行されるトランザクションとそれに対応するリソース ロックによって引き起こされる悪影響が観察されます。

BPM スタイルのビジネス プロセスに関して、「Saga」の実装は非常に簡単であることがわかりました。「Saga」の個々のステップはビジネス プロセス内のアクティビティとして指定でき、ビジネス プロセスの永続的な状態も指定できます。 「Saga」の内部状態を決定します。 つまり、追加の調整メカニズムは必要ありません。 必要なのは、トランスポートとして「少なくとも XNUMX 回」の保証をサポートするメッセージ ブローカーだけです。

ただし、このソリューションには独自の「代償」もあります。

• ビジネス ロジックはより複雑になります。補償を検討する必要があります。
• 完全な一貫性を放棄する必要がありますが、これはモノリシック システムでは特に注意が必要です。
• アーキテクチャはもう少し複雑になり、メッセージ ブローカーがさらに必要になります。
• 追加の監視および管理ツールが必要になります (ただし、一般的にはこれは良いことであり、システム サービスの品質が向上します)。

モノリシック システムの場合、「サグ」を使用する正当な理由はそれほど明白ではありません。 マイクロサービスやその他の SOA では、ブローカーがすでに存在し、プロジェクトの開始時に完全な一貫性が犠牲になる可能性が高く、特にビジネス ロジックに便利な API がある場合、このパターンを使用する利点が欠点を大幅に上回る可能性があります。レベル。

ビジネス ロジックをマイクロサービスにカプセル化する

マイクロサービスの実験を開始したとき、当然の疑問が生じました。ドメイン データの永続性を保証するサービスに関連して、ドメイン ビジネス ロジックをどこに配置するかということです。

さまざまな BPMS のアーキテクチャを見ると、ビジネス ロジックを永続性から分離するのが合理的であるように思えるかもしれません。ドメイン ビジネス ロジックを実行するための環境とコンテナーを形成するプラットフォームとドメインに依存しないマイクロサービスの層を作成し、ドメイン データの永続性を次のように設計します。非常にシンプルで軽量なマイクロサービスの別個のレイヤー。 この場合のビジネス プロセスは、永続層のサービスのオーケストレーションを実行します。

このアプローチには非常に大きな利点があります。プラットフォームの機能を好きなだけ増やすことができ、プラットフォーム マイクロサービスの対応するレイヤーのみが今後「肥大化」します。 プラットフォームの新機能が更新されると、どのドメインのビジネス プロセスでもすぐに使用できるようになります。

より詳細な調査により、このアプローチの重大な欠点が明らかになりました。

• 多くのドメインのビジネス ロジックを一度に実行するプラットフォーム サービスは、単一障害点として大きなリスクを伴います。 ビジネス ロジックを頻繁に変更すると、システム全体の障害につながるエラーのリスクが高まります。
• パフォーマンスの問題: ビジネス ロジックは、狭くて遅いインターフェイスを通じてデータを処理します。
  • データは再びマーシャリングされ、ネットワーク スタックを通じて送られます。
  • ドメイン サービスは、サービスの外部 API レベルでリクエストをパラメータ化する機能が不十分なため、ビジネス ロジックの処理に必要なデータよりも多くのデータを提供することがよくあります。
  • ビジネス ロジックのいくつかの独立した部分は、処理のために同じデータを繰り返し再要求する可能性があります (この問題は、データをキャッシュするセッション コンポーネントを追加することで軽減できますが、これによりアーキテクチャがさらに複雑になり、データの関連性とキャッシュの無効化の問題が発生します)。
• トランザクションの問題:
  • プラットフォーム サービスによって保存される永続的な状態を持つビジネス プロセスはドメイン データと矛盾しており、この問題を解決する簡単な方法はありません。
  • ドメイン データ ブロックをトランザクションの外部に配置する: 現在のデータの正確性を最初に確認した後でドメイン ビジネス ロジックを変更する必要がある場合は、処理されたデータに競合する変更が発生する可能性を排除する必要があります。 外部データのブロックは問題の解決に役立ちますが、そのような解決策にはさらなるリスクが伴い、システム全体の信頼性が低下します。
• 更新時の追加の問題: 場合によっては、永続化サービスとビジネス ロジックを同期的に、または厳密な順序で更新する必要があります。

最終的には、ドメイン データとドメイン ビジネス ロジックを XNUMX つのマイクロサービスにカプセル化するという基本に立ち返る必要がありました。 このアプローチは、マイクロサービスをシステムの不可欠なコンポーネントとして認識することを簡素化し、上記の問題を引き起こしません。 これも無料では提供されません。

• API 標準化は、ビジネス ロジック (特に、ビジネス プロセスの一部としてユーザー アクティビティを提供する) および API プラットフォーム サービスとの対話に必要です。 API の変更、上位互換性および下位互換性については、より細心の注意を払う必要があります。
• このような各マイクロサービスの一部としてビジネス ロジックが確実に機能するようにするには、ランタイム ライブラリを追加する必要があります。これにより、そのようなライブラリに対する新しい要件が生じます。軽量性と推移的な依存関係が最小限であること。
• ビジネス ロジック開発者はライブラリのバージョンを監視する必要があります。マイクロサービスが長期間完成していない場合、古いバージョンのライブラリが含まれている可能性が高くなります。 これは、新しい機能を追加する際の予期せぬ障害となる可能性があり、バージョン間に互換性のない変更があった場合には、そのようなサービスの古いビジネス ロジックをライブラリの新しいバージョンに移行することが必要になる場合があります。

このようなアーキテクチャにはプラットフォーム サービスの層も存在しますが、この層はドメイン ビジネス ロジックを実行するためのコンテナを形成せず、その環境のみを形成し、補助的な「プラットフォーム」機能を提供します。 このようなレイヤーは、ドメイン マイクロサービスの軽量性を維持するためだけでなく、管理を一元化するためにも必要です。

たとえば、ビジネス プロセス内のユーザー アクティビティによってタスクが生成されます。 ただし、タスクを操作する場合、ユーザーは一般リスト内のすべてのドメインのタスクを表示する必要があります。これは、ドメイン ビジネス ロジックを排除した、対応するプラットフォーム タスク登録サービスが必要であることを意味します。 このようなコンテキストでビジネス ロジックのカプセル化を維持することは非常に問題があり、これもこのアーキテクチャの妥協点です。

アプリケーション開発者の視点から見たビジネスプロセスの統合

上で述べたように、アプリケーション開発者は、優れた開発生産性を期待できるように、複数のアプリケーションの相互作用を実装する技術的およびエンジニアリング的機能から抽象化する必要があります。

この記事のために特別に考案された、かなり難しい積分問題を解いてみましょう。 これは 1 つのアプリケーションを含む「ゲーム」タスクとなり、それぞれが特定のドメイン名「app2」、「app3」、「appXNUMX」を定義します。

各アプリケーション内でビジネス プロセスが起動され、統合バスを通じて「ボール遊び」が始まります。 「Ball」という名前のメッセージはボールとして機能します。

ゲームのルール：

• 最初のプレイヤーがイニシエーターです。 彼は他のプレイヤーをゲームに招待し、ゲームを開始し、いつでも終了できます。
• 他のプレイヤーはゲームへの参加を宣言し、お互いと最初のプレイヤーを「知ります」。
• ボールを受け取った後、プレーヤーは他の参加プレーヤーを選択し、そのプレーヤーにボールを渡します。 送信の総数がカウントされます。
• 各プレーヤーは「エネルギー」を持っており、そのプレーヤーがボールをパスするたびに減少します。 エネルギーが尽きると、プレイヤーは辞任を表明してゲームから離れます。
• プレーヤーが一人になった場合、プレーヤーはすぐに退場を宣言します。
• すべてのプレイヤーが脱落すると、最初のプレイヤーがゲーム終了を宣言します。 彼が早期にゲームを終了した場合、彼はゲームを完了するために残ります。

この問題を解決するために、ビジネス プロセスに DSL を使用します。これにより、最小限の定型文で Kotlin のロジックをコンパクトに記述することができます。

最初のプレーヤー (別名、ゲームの開始者) のビジネス プロセスは、app1 アプリケーションで動作します。

クラスInitialPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.constraint.UniqueConstraints
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.dsl.taskOperation
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList : ArrayList<PlayerInfo>()

// Это класс экземпляра процесса: инкапсулирует его внутреннее состояние
class InitialPlayer : ProcessImpl<InitialPlayer>(initialPlayerModel) {
    var playerName: String by persistent("Player1")
    var energy: Int by persistent(30)
    var players: PlayersList by persistent(PlayersList())
    var shotCounter: Int = 0
}

// Это декларация модели процесса: создается один раз, используется всеми
// экземплярами процесса соответствующего класса
val initialPlayerModel = processModel<InitialPlayer>(name = "InitialPlayer",
                                                     version = 1) {

    // По правилам, первый игрок является инициатором игры и должен быть единственным
    uniqueConstraint = UniqueConstraints.singleton

    // Объявляем активности, из которых состоит бизнес-процесс
    val sendNewGameSignal = signal<String>("NewGame")
    val sendStopGameSignal = signal<String>("StopGame")
    val startTask = humanTask("Start") {
        taskOperation {
            processCondition { players.size > 0 }
            confirmation { "Подключилось ${players.size} игроков. Начинаем?" }
        }
    }
    val stopTask = humanTask("Stop") {
        taskOperation {}
    }
    val waitPlayerJoin = signalWait<String>("PlayerJoin") { signal ->
        players.add(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... join player ${signal.data} ...")
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... player ${signal.data} is out ...")
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val throwStartBall = messageSend<Int>("Ball") {
        messageData = { 1 }
        activation = { selectNextPlayer() }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    // Теперь конструируем граф процесса из объявленных активностей
    startFrom(sendNewGameSignal)
            .fork("mainFork") {
                next(startTask)
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut)
                        .branch("checkPlayers") {
                            ifTrue { players.isEmpty() }
                                    .next(sendStopGameSignal)
                                    .terminate()
                            ifElse().next(waitPlayerOut)
                        }
            }
    startTask.fork("afterStart") {
        next(throwStartBall)
                .branch("mainLoop") {
                    ifTrue { energy < 5 }.next(sendPlayerOut).next(waitBall)
                    ifElse().next(waitBall).next(throwBall).loop()
                }
        next(stopTask).next(sendStopGameSignal)
    }

    // Навешаем на активности дополнительные обработчики для логирования
    sendNewGameSignal.onExit { println("Let's play!") }
    sendStopGameSignal.onExit { println("Stop!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<InitialPlayer, Int>.selectNextPlayer() {
    val player = process.players.random()
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

ビジネス ロジックの実行に加えて、上記のコードは、図の形式で視覚化できるビジネス プロセスのオブジェクト モデルを生成できます。 ビジュアライザーをまだ実装していないため、描画に少し時間を費やす必要がありました (ここでは、図と以下のコードの一貫性を高めるために、ゲートの使用に関する BPMN 表記を少し簡略化しました)。

app2 には、他のプレーヤーのビジネス プロセスが含まれます。

クラスRandomPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RandomPlayer : ProcessImpl<RandomPlayer>(randomPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RandomPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val randomPlayerModel = processModel<RandomPlayer>(name = "RandomPlayer", 
                                                   version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!,
                    signal.sender.domain,
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RandomPlayer, Int>.selectNextPlayer() {
    val player = if (process.players.isNotEmpty()) 
        process.players.random() 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

図：

app3 アプリケーションでは、少し異なる動作を持つプレーヤーを作成します。次のプレーヤーをランダムに選択する代わりに、ラウンドロビン アルゴリズムに従って動作します。

クラスRoundRobinPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RoundRobinPlayer : ProcessImpl<RoundRobinPlayer>(roundRobinPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RoundRobinPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var nextPlayerIndex: Int by persistent(-1)
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val roundRobinPlayerModel = processModel<RoundRobinPlayer>(
        name = "RoundRobinPlayer", 
        version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!, 
                    signal.sender.domain, 
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!, 
                signal.sender.domain, 
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RoundRobinPlayer, Int>.selectNextPlayer() {
    var idx = process.nextPlayerIndex + 1
    if (idx >= process.players.size) {
        idx = 0
    }
    process.nextPlayerIndex = idx
    val player = if (process.players.isNotEmpty()) 
        process.players[idx] 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

それ以外の場合、プレイヤーの行動は前回と変わらないため、図は変わりません。

ここで、これらすべてを実行するためのテストが必要です。 定型文で記事が乱雑にならないように、テスト自体のコードのみを示します (実際、他のビジネス プロセスの統合をテストするために以前に作成したテスト環境を使用しました)。

テストゲーム()

@Test
public void testGame() throws InterruptedException {
    String pl2 = startProcess(app2, "RandomPlayer", playerParams("Player2", 20));
    String pl3 = startProcess(app2, "RandomPlayer", playerParams("Player3", 40));
    String pl4 = startProcess(app3, "RoundRobinPlayer", playerParams("Player4", 25));
    String pl5 = startProcess(app3, "RoundRobinPlayer", playerParams("Player5", 35));
    String pl1 = startProcess(app1, "InitialPlayer");
    // Теперь нужно немного подождать, пока игроки "познакомятся" друг с другом.
    // Ждать через sleep - плохое решение, зато самое простое. 
    // Не делайте так в серьезных тестах!
    Thread.sleep(1000);
    // Запускаем игру, закрывая пользовательскую активность
    assertTrue(closeTask(app1, pl1, "Start"));
    app1.getWaiting().waitProcessFinished(pl1);
    app2.getWaiting().waitProcessFinished(pl2);
    app2.getWaiting().waitProcessFinished(pl3);
    app3.getWaiting().waitProcessFinished(pl4);
    app3.getWaiting().waitProcessFinished(pl5);
}

private Map<String, Object> playerParams(String name, int energy) {
    Map<String, Object> params = new HashMap<>();
    params.put("playerName", name);
    params.put("energy", energy);
    return params;
}

テストを実行してログを見てみましょう。

コンソール出力

Взята блокировка ключа lock://app1/process/InitialPlayer
Let's play!
Снята блокировка ключа lock://app1/process/InitialPlayer
Player2: I'm here!
Player3: I'm here!
Player4: I'm here!
Player5: I'm here!
... join player Player2 ...
... join player Player4 ...
... join player Player3 ...
... join player Player5 ...
Step 1: Player1 >>> Player3
Step 2: Player3 >>> Player5
Step 3: Player5 >>> Player3
Step 4: Player3 >>> Player4
Step 5: Player4 >>> Player3
Step 6: Player3 >>> Player4
Step 7: Player4 >>> Player5
Step 8: Player5 >>> Player2
Step 9: Player2 >>> Player5
Step 10: Player5 >>> Player4
Step 11: Player4 >>> Player2
Step 12: Player2 >>> Player4
Step 13: Player4 >>> Player1
Step 14: Player1 >>> Player4
Step 15: Player4 >>> Player3
Step 16: Player3 >>> Player1
Step 17: Player1 >>> Player2
Step 18: Player2 >>> Player3
Step 19: Player3 >>> Player1
Step 20: Player1 >>> Player5
Step 21: Player5 >>> Player1
Step 22: Player1 >>> Player2
Step 23: Player2 >>> Player4
Step 24: Player4 >>> Player5
Step 25: Player5 >>> Player3
Step 26: Player3 >>> Player4
Step 27: Player4 >>> Player2
Step 28: Player2 >>> Player5
Step 29: Player5 >>> Player2
Step 30: Player2 >>> Player1
Step 31: Player1 >>> Player3
Step 32: Player3 >>> Player4
Step 33: Player4 >>> Player1
Step 34: Player1 >>> Player3
Step 35: Player3 >>> Player4
Step 36: Player4 >>> Player3
Step 37: Player3 >>> Player2
Step 38: Player2 >>> Player5
Step 39: Player5 >>> Player4
Step 40: Player4 >>> Player5
Step 41: Player5 >>> Player1
Step 42: Player1 >>> Player5
Step 43: Player5 >>> Player3
Step 44: Player3 >>> Player5
Step 45: Player5 >>> Player2
Step 46: Player2 >>> Player3
Step 47: Player3 >>> Player2
Step 48: Player2 >>> Player5
Step 49: Player5 >>> Player4
Step 50: Player4 >>> Player2
Step 51: Player2 >>> Player5
Step 52: Player5 >>> Player1
Step 53: Player1 >>> Player5
Step 54: Player5 >>> Player3
Step 55: Player3 >>> Player5
Step 56: Player5 >>> Player2
Step 57: Player2 >>> Player1
Step 58: Player1 >>> Player4
Step 59: Player4 >>> Player1
Step 60: Player1 >>> Player4
Step 61: Player4 >>> Player3
Step 62: Player3 >>> Player2
Step 63: Player2 >>> Player5
Step 64: Player5 >>> Player4
Step 65: Player4 >>> Player5
Step 66: Player5 >>> Player1
Step 67: Player1 >>> Player5
Step 68: Player5 >>> Player3
Step 69: Player3 >>> Player4
Step 70: Player4 >>> Player2
Step 71: Player2 >>> Player5
Step 72: Player5 >>> Player2
Step 73: Player2 >>> Player1
Step 74: Player1 >>> Player4
Step 75: Player4 >>> Player1
Step 76: Player1 >>> Player2
Step 77: Player2 >>> Player5
Step 78: Player5 >>> Player4
Step 79: Player4 >>> Player3
Step 80: Player3 >>> Player1
Step 81: Player1 >>> Player5
Step 82: Player5 >>> Player1
Step 83: Player1 >>> Player4
Step 84: Player4 >>> Player5
Step 85: Player5 >>> Player3
Step 86: Player3 >>> Player5
Step 87: Player5 >>> Player2
Step 88: Player2 >>> Player3
Player2: I'm out!
Step 89: Player3 >>> Player4
... player Player2 is out ...
Step 90: Player4 >>> Player1
Step 91: Player1 >>> Player3
Step 92: Player3 >>> Player1
Step 93: Player1 >>> Player4
Step 94: Player4 >>> Player3
Step 95: Player3 >>> Player5
Step 96: Player5 >>> Player1
Step 97: Player1 >>> Player5
Step 98: Player5 >>> Player3
Step 99: Player3 >>> Player5
Step 100: Player5 >>> Player4
Step 101: Player4 >>> Player5
Player4: I'm out!
... player Player4 is out ...
Step 102: Player5 >>> Player1
Step 103: Player1 >>> Player3
Step 104: Player3 >>> Player1
Step 105: Player1 >>> Player3
Step 106: Player3 >>> Player5
Step 107: Player5 >>> Player3
Step 108: Player3 >>> Player1
Step 109: Player1 >>> Player3
Step 110: Player3 >>> Player5
Step 111: Player5 >>> Player1
Step 112: Player1 >>> Player3
Step 113: Player3 >>> Player5
Step 114: Player5 >>> Player3
Step 115: Player3 >>> Player1
Step 116: Player1 >>> Player3
Step 117: Player3 >>> Player5
Step 118: Player5 >>> Player1
Step 119: Player1 >>> Player3
Step 120: Player3 >>> Player5
Step 121: Player5 >>> Player3
Player5: I'm out!
... player Player5 is out ...
Step 122: Player3 >>> Player5
Step 123: Player5 >>> Player1
Player5: I'm out!
Step 124: Player1 >>> Player3
... player Player5 is out ...
Step 125: Player3 >>> Player1
Step 126: Player1 >>> Player3
Player1: I'm out!
... player Player1 is out ...
Step 127: Player3 >>> Player3
Player3: I'm out!
Step 128: Player3 >>> Player3
... player Player3 is out ...
Player3: I'm out!
Stop!
Step 129: Player3 >>> Player3
Player3: I'm out!

これらすべてから、いくつかの重要な結論を導き出すことができます。

• 必要なツールを使用すると、アプリケーション開発者はビジネス ロジックを中断することなく、アプリケーション間の統合対話を作成できます。
• エンジニアリング能力を必要とする統合タスクの複雑さは、最初からフレームワークのアーキテクチャに含まれている場合、フレームワーク内に隠すことができます。 問題の難しさは隠すことができないので、コードでの難しい問題の解決策はそのようになります。
• 統合ロジックを開発するときは、最終的な整合性と、すべての統合参加者の状態変化の線形性の欠如を考慮することが不可欠です。 このため、外部イベントが発生する順序に影響されないようにするために、ロジックを複雑にする必要があります。 この例では、プレイヤーはゲームからの退場を宣言した後、ゲームに強制的に参加することになります。彼の退場に関する情報がすべての参加者に届き、処理されるまで、他のプレイヤーは彼にボールをパスし続けます。 このロジックはゲームのルールに従っておらず、選択したアーキテクチャのフレームワーク内での妥協的な解決策です。

次に、ソリューションのさまざまな複雑さ、妥協点、その他の点について説明します。

すべてのメッセージは XNUMX つのキューにあります

すべての統合アプリケーションは、外部ブローカーの形式で提供される XNUMX つの統合バス、メッセージ用の XNUMX つの BPMQueue、および信号 (イベント) 用の XNUMX つの BPMTopic トピックで動作します。 すべてのメッセージを XNUMX つのキューに通すこと自体が妥協です。 ビジネス ロジック レベルでは、システム構造を変更せずに、新しいメッセージ タイプを好きなだけ導入できるようになりました。 これは大幅な簡素化ですが、一定のリスクを伴います。私たちの典型的なタスクの文脈では、それは私たちにとってそれほど重要ではありませんでした。

ただし、ここには微妙な点が XNUMX つあります。各アプリケーションは、入口のキューから「その」メッセージをそのドメインの名前でフィルタリングします。 信号の「可視性の範囲」を XNUMX つのアプリケーションに制限する必要がある場合は、信号内でドメインを指定することもできます。 これによりバスのスループットが向上しますが、ビジネス ロジックはドメイン名を使用して動作する必要があります。メッセージのアドレス指定の場合は必須、信号の場合は望ましいです。

統合バスの信頼性の確保

信頼性はいくつかのポイントで構成されます。

• 選択したメッセージ ブローカーは、アーキテクチャの重要なコンポーネントであり、単一障害点であるため、十分な耐障害性を備えている必要があります。 優れたサポートと大規模なコミュニティを備えた、実績のある実装のみを使用する必要があります。
• メッセージ ブローカーの高可用性を確保する必要があり、統合アプリケーションからメッセージ ブローカーを物理的に分離する必要があります (ビジネス ロジックが適用されたアプリケーションの高可用性を確保することははるかに困難であり、コストがかかります)。
• ブローカーは「少なくとも XNUMX 回」の配送保証を提供する義務があります。 これは、統合バスを確実に動作させるための必須要件です。 「XNUMX 回だけ」レベルの保証は必要ありません。ビジネス プロセスは、原則として、メッセージやイベントの繰り返しの到着に敏感ではなく、これが重要な特別なタスクでは、ビジネスに追加のチェックを追加する方が簡単です。非常に「高価な」保証を常に使用するよりも論理的です。
• メッセージとシグナルの送信は、ビジネス プロセスとドメイン データの状態の変化を伴うトランザクション全体に関与する必要があります。 推奨されるオプションはパターンを使用することです トランザクション送信ボックスただし、データベース内に追加のテーブルとリピーターが必要になります。 JEE アプリケーションでは、ローカル JTA マネージャーを使用することでこれを簡素化できますが、選択したブローカーへの接続が機能する必要があります。 XA;
• 受信メッセージとイベントのハンドラーは、ビジネス プロセスの状態を変更するトランザクションとも連携する必要があります。そのようなトランザクションがロールバックされた場合は、メッセージの受信をキャンセルする必要があります。
• エラーにより配信できなかったメッセージは別のストレージに保存する必要がある DLQ (デッドレターキュー)。 この目的のために、このようなメッセージをストレージに保存し、(素早いグループ化と検索のために) 属性ごとにインデックスを付け、メッセージの表示、宛先アドレスへの再送信、削除のための API を公開する別のプラットフォーム マイクロサービスを作成しました。 システム管理者は、Web インターフェイスを通じてこのサービスを操作できます。
• ブローカー設定では、メッセージが DLQ に入る可能性を減らすために、配信の再試行回数と配信間の遅延を調整する必要があります (最適なパラメータを計算することはほぼ不可能ですが、経験に基づいて操作し、運用中に調整することができます) );
• DLQ ストアは継続的に監視する必要があり、監視システムはメッセージの未配信が発生した場合にシステム管理者ができるだけ早く対応できるようにシステム管理者に警告する必要があります。 これにより、障害またはビジネス ロジック エラーの「影響を受ける領域」が減少します。
• 統合バスは、アプリケーションが一時的に存在しなくても影響を受けないようにする必要があります。トピックへのサブスクリプションは永続的である必要があり、アプリケーションが存在しない間、他のユーザーがそのアプリケーションからのメッセージを処理しようとしないように、アプリケーションのドメイン名は一意でなければなりません。列。

ビジネスロジックのスレッドセーフ性の確保

ビジネス プロセスの同じインスタンスは、複数のメッセージとイベントを同時に受信でき、それらの処理は並行して開始されます。 同時に、アプリケーション開発者にとっては、すべてがシンプルでスレッドセーフである必要があります。

プロセスのビジネス ロジックは、そのビジネス プロセスに影響を与える各外部イベントを個別に処理します。 そのようなイベントには次のようなものがあります。

• ビジネスプロセスインスタンスを起動する。
• ビジネスプロセス内のアクティビティに関連するユーザーアクション。
• ビジネス プロセス インスタンスがサブスクライブされているメッセージまたはシグナルの受信。
• ビジネス プロセス インスタンスによって設定されたタイマーのトリガー。
• API を介してアクションを制御します (プロセスの中断など)。

このような各イベントは、ビジネス プロセス インスタンスの状態を変更する可能性があります。アクティビティによっては終了する場合もあれば開始する場合もあり、永続プロパティの値が変更される場合もあります。 アクティビティを閉じると、次のアクティビティの XNUMX つ以上がアクティブ化される場合があります。 これらは、他のイベントの待機を停止することも、追加のデータが必要ない場合は同じトランザクションで完了することもできます。 トランザクションを閉じる前に、ビジネス プロセスの新しい状態がデータベースに保存され、そこで次の外部イベントが発生するのを待ちます。

リレーショナル データベースに保存された永続的なビジネス プロセス データは、SELECT FOR UPDATE を使用する場合の同期処理に非常に便利です。 XNUMX つのトランザクションが、ビジネス プロセスを変更するためにベースからビジネス プロセスの状態を取得できた場合、並行して実行されている他のトランザクションは別の変更に対して同じ状態を取得できなくなり、最初のトランザクションが完了すると、XNUMX 番目のトランザクションが取得されます。すでに変更された状態を受け取ることが保証されています。

DBMS 側で悲観的ロックを使用することで、必要な要件をすべて満たします ACIDまた、実行中のインスタンスの数を増やすことで、ビジネス ロジックを使用してアプリケーションを拡張する機能も保持します。

ただし、悲観的なロックはデッドロックの脅威となるため、ビジネス ロジックの重大なケースでデッドロックが発生した場合に備えて、SELECT FOR UPDATE を適切なタイムアウトに制限する必要があります。

もう XNUMX つの問題は、ビジネス プロセスの開始の同期です。 ビジネス プロセスのインスタンスはありませんが、データベースには状態がないため、説明したメソッドは機能しません。 特定のスコープ内でビジネス プロセス インスタンスの一意性を保証する必要がある場合は、プロセス クラスと対応するスコープに関連付けられたある種の同期オブジェクトが必要になります。 この問題を解決するために、外部サービスを通じて URI 形式のキーで指定された任意のリソースをロックできるようにする別のロック メカニズムを使用します。

この例では、InitialPlayer ビジネス プロセスに宣言が含まれています。

uniqueConstraint = UniqueConstraints.singleton

したがって、ログには、対応するキーのロックの取得と解放に関するメッセージが含まれます。 他のビジネス プロセスにはそのようなメッセージはありません: uniqueConstraint が設定されていません。

永続的な状態を持つビジネスプロセスの問題

場合によっては、永続的な状態を維持することは、開発に役立つだけでなく、実際の開発を妨げることもあります。
問題は、ビジネス ロジックやビジネス プロセス モデルに変更を加える必要があるときに始まります。 このような変更すべてがビジネス プロセスの古い状態と互換性があるわけではありません。 データベース内に多数のライブ インスタンスがある場合、互換性のない変更を行うと多くの問題が発生する可能性があります。これは、jBPM を使用するときによく発生します。

変更の深さに応じて、次の XNUMX つの方法で対処できます。

1. 古いビジネス プロセス タイプに互換性のない変更を加えないように新しいビジネス プロセス タイプを作成し、新しいインスタンスを起動するときに古いタイプの代わりにそれを使用します。 古いコピーは「以前と同じように」動作し続けます。
2. ビジネス ロジックを更新するときに、ビジネス プロセスの永続的な状態を移行します。

最初の方法は簡単ですが、次のような制限と欠点があります。

• 多くのビジネス プロセス モデルでビジネス ロジックが重複し、ビジネス ロジックの量が増加します。
• 多くの場合、新しいビジネス ロジックへの即時移行が必要になります (統合タスクに関しては、ほとんどの場合)。
• 開発者には、古いモデルをどの時点で削除できるかわかりません。

実際には両方のアプローチを使用していますが、作業を楽にするためにいくつかの決定を下しました。

• データベースでは、ビジネス プロセスの永続的な状態が、読み取りやすく処理が容易な形式、つまり JSON 形式の文字列で保存されます。 これにより、アプリケーション内と外部の両方で移行を実行できるようになります。 最後の手段として、手動で修正することができます (特に開発中のデバッグ中に役立ちます)。
• 統合ビジネス ロジックではビジネス プロセスの名前が使用されないため、参加プロセスの 2 つの実装を新しい名前 (たとえば、「InitialPlayerVXNUMX」など) の新しい実装にいつでも置き換えることができます。 バインディングはメッセージ名とシグナル名を通じて行われます。
• プロセス モデルにはバージョン番号があり、このモデルに互換性のない変更を加えた場合にこの番号が増分され、この番号はプロセス インスタンスの状態とともに保存されます。
• プロセスの永続的な状態は、最初にデータベースから便利なオブジェクト モデルに読み取られ、モデルのバージョン番号が変更された場合に移行手順で使用できます。
• 移行手順はビジネス ロジックの隣に配置され、データベースからの復元時にビジネス プロセスの各インスタンスに対して「遅延」と呼ばれます。
• すべてのプロセス インスタンスの状態を迅速かつ同期的に移行する必要がある場合は、より古典的なデータベース移行ソリューションが使用されますが、JSON を使用する必要があります。

ビジネスプロセスに別のフレームワークが必要ですか?

この記事で説明されているソリューションにより、私たちの生活が大幅に簡素化され、アプリケーション開発レベルで解決できる問題の範囲が拡大し、ビジネス ロジックをマイクロサービスに分離するというアイデアがより魅力的なものになりました。 これを達成するために、多くの作業が行われ、ビジネス プロセス用の非常に「軽量」なフレームワークが作成され、また、アプリケーションの幅広い問題のコンテキストで特定された問題を解決するためのサービス コンポーネントも作成されました。 私たちはこれらの結果を共有し、共通コンポーネントの開発を無料ライセンスの下でオープンアクセスにしたいと考えています。 これにはある程度の労力と時間が必要になります。 このようなソリューションに対する需要を理解することは、私たちにとってさらなるインセンティブとなる可能性があります。 提案された記事では、フレームワーク自体の機能にはほとんど注意が払われませんが、提示された例からその一部が見えてきます。 フレームワークを公開する場合は、別の記事でそれについて取り上げます。 それまでの間、次の質問に答えてフィードバックを残していただければ幸いです。

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

ビジネスプロセスに別のフレームワークが必要ですか?

• 視聴者の３８%がはい、このようなものを長い間探していました

• 視聴者の３８%があなたの実装について詳しく知りたいのですが、役立つかもしれません2

• 視聴者の３８%が既存のフレームワークの 1 つを使用していますが、置き換えることを検討していますXNUMX

• 視聴者の３８%が既存のフレームワークの 3 つを使用していますが、すべて問題ありませんXNUMX

• 視聴者の３８%が私たちはフレームワークなしで管理します3

• 視聴者の３８%が自分のことを書いてください4

16 人のユーザーが投票しました。 7名のユーザーが棄権した。

出所： habr.com