コントロールセンターの核となる考え方
目標へ直接: ビジネス フロー制御を一元管理するコア処理モジュールを設計し、ビジネス モジュール間の相互作用、モジュール間のデータの流れ、インターフェイスのドッキング方法を構成します。
設計思想：エージェントベースのプロセス制御、モジュール化、パブリックインターフェース
大きな選択肢:
実装内容
1. ビジネスプロセスの構成
2. プロジェクトのライフサイクルとプロセスのステータスの監視
3. 動的モジュールのロード
4. インターフェース定義の修正（継承プロトコル（インターフェース））
5. インターセプターベースのビジネス管理
実装のアイデア
1. デザインモードの選択: アダプターモード + エージェントモード + ファサードモード
2. エンティティ関係の選択: 低結合分離関係
3. アクセス方法：コントローラレベルの「アノテーション」でサービスIDを定義
4. 構成ファイル: サービス ID セマンティクス、モジュール タイプ、およびデフォルトのフローチャートを構成します。
5. フロントエンドドッキング: ファサードドッキング、ビジネスとビューの分離、すべてのビジネスフロー制御コードの抽出と分離
6. アーキテクチャ モード: センター モード、スケジューラなし、パブリック インターフェイス
7. 例外処理と解決: 注釈を利用した印刷、迅速な位置決め、システム例外のキャッチと解決
模式図
1. コントロール センターは、ビジネス ジャンプを引き起こすすべてのリクエストをフィルタリングする責任があります (各リクエストは次で終わります)@Checkpointアノテーション)、インターセプターによって識別されます。
2. モジュールはモジュール間の通信のための標準対話 API のみを提供でき、内部プロセスは制御に関与しません。
3. コントロールセンターはモジュールの通信履歴を記録し、ログに書き込みます。ジャンプ発生時に許可検証が行われます。
4. モジュール間にはタイミングの問題があります。つまり、モジュールにはプレモジュールがあり、そのプレモジュールには独自のプレモジュールも含まれる可能性があります。
5. モジュールの統一データ単位: プロジェクト コード。
6. 終了モジュール: プロジェクトを終了する性質を持つモジュールですが、プロセスを直接終了することはできず、コントロール センターに委託する必要があります。
|
モジュールA |
A – B 緑 B – 終端された黒
|
プロジェクトの終了 |
|
コントロールセンター |
|
ユーザー設定 |
|
|
|
構成データベース |
|
モジュールB |
|
モジュール C (終了) |
実施原則
1. プロジェクトはコード レベルでプロジェクトを区別しなくなり、パブリック プロパティを含む基本クラスであるスーパー クラス Project を使用します。問い合わせ、入札、入札などのプロジェクトはすべてサブクラスとして実装され、データベース レベルは変わりません。
2. コードやタイプなどのすべてのプロジェクトの共通属性は、モジュール インターフェイスの対話のための重要なデータとして使用されます。
3. プロジェクトのステータス変更、基本属性の変更、およびストレージのトリガー 関連する実装は、ControlCenter のアダプタの形式で実装されます（プロジェクト カテゴリごとに 1 つのアダプタ）
4. モジュールは入口モジュールと出口モジュールに分かれており、入口は通常プロジェクトの作成であり、出口は通常プロジェクトの終了です。
5. 通知およびストレージ関連の実装は、コントロール センター エージェントの実装と同等のモジュール内のコールバックの形式で実装されます。実装コードはモジュール内に配置され、プロセス コントローラーがトリガーされたときに実行されます。
6. コントロール センターは唯一のファサードを提供しますが、アクティブなトリガー インターフェイスのみを公開し、ビジネス関連のインターフェイスは公開しません。
ビジネスカップリング
プロセス制御モジュールは業務上の大きな結合関係があり、プロセスに設定可能なモジュールを挿入すると、現在追加されているモジュールに応じて後続のモジュールの内容もある程度変化するため、それぞれに固有の実装を行う必要があります。構成可能なモジュール ビジネス コードの実装場所は、新しいモジュールの変更に対応する後続のモジュールで構成されたコード ブロックです。
したがって、前提となる原則は次のとおりです。
このオプション モジュールのすべてのサポートが実装され、含まれている 場合にのみ、このオプション モジュールをこれらのビジネス モジュールのプレモジュールとして使用できます。
状態制御には予測できないオプションモジュールの制約が含まれるため、すべての予測不可能なものを予測可能なものに変換する必要があります。つまり、メイン プロセスのすべての事後位置が考慮され、レビュー中、登録、変更レビューなどの特別なプロジェクト ステータスが作成され、オプションのモジュールに処理が委ねられます。モジュールのライフサイクルが終了すると、モジュール自体は動作しなくなり、次のモジュールに引き渡されて、前のモジュールの終了時に残された状態に基づいて関連する動作が実行されます。したがって、次のような結論に達します。
モジュールはポストモジュール自体の特定の状況を判断する必要はなく、プレモジュールがそれ自身に与える影響を考慮するだけで済みます。すべての背面モジュールは、前面モジュールと一致し、拡張されている必要があります。
受信インターフェースと送信インターフェース
ビジネス モジュールの標準化は非常に重要であり、統一されたインターフェイスを提供することでメンテナンスが容易になり、コードの品質も向上します。
インターフェース仕様パターン図は以下のとおりです。
構成センター
構成センターの UI 実装は、プロセスの表示と構成のための入り口をユーザーに公開するために使用されます。
きめ細かなデザイン
1. モジュールロードスキャン
Application イベントを使用して、ModuleDefine アノテーションによって宣言されたすべてのビジネス モジュールを Bean コンテナから削除します。
2. モジュール呼び出しチェーン
リクエスト -> コントロールセンター -> モジュール onExit -> リクエストロジック -> 次のモジュール onEnter
3. フロントエンド処理
コントロール センター情報を使用して ajax リクエストをインターセプトし、コントロール センターの指示を処理し、ジャンプまたはリリースを完了します。
4. モジュールエージェント
共通の操作を実行し、モジュールのライフサイクルに対して統一されたスケジューリングを実行します。