Pega のケース設計
何をケースにし、ステージとフローにどう分け、親子や並列の処理をどう組むかを扱う記事です。
この領域で判断すること
ケース設計は、後から直すと費用がもっとも大きくなる判断の一つです。ケースにするかデータにするか、ステージとフローの責務、子ケースとサブプロセス、SLA、ロックの競合、例外の経路など、設計の分かれ目ごとに判断基準をまとめています。
最初に読む
- 01 Pega設計の分岐点：ケースにすべきか、データインスタンスか
Pega 設計で最初に直面する「これはケース？それともデータインスタンス？」という判断を、独立したライフサイクル・業務の進行管理（割当・承認・SLA・監査）・件数と寿命の観点で整理し、実案件での判断基準を具体例とともに解説します。
- 02 Pega ケースライフサイクルとフローの責務分担｜ステージ設計の判断
同じ業務でも、ステージ/ステップとして高レベルに表現するか、フローの中に手続きとして書き込むかで、後々の可読性・変更容易性・再利用性がまるで違う。責務を混在させた巨大フローや、ステップ代わりのステージ乱立は典型的な負債になる。ケースライフサイクルとフローの責務分担を、分岐をどちらに持たせるかの判断まで含めて整理する。
- 03 Pega 親子ケース設計｜子ケースに分割すべきかの判断基準と失敗例
業務を子ケースに切り出すべきか、それとも親ケースのステージ/ステップに収めるべきか。判断を誤ると、独立追跡できずに再設計になったり、逆にケースインスタンスが増えすぎて運用とレポートが破綻したりする。この記事では、親子ケースに分割する境界線を「独立したライフサイクルを持つか」を軸に、待ち合わせ(依存)設計まで含めて解説する。
このテーマの記事（5 本）
関連するご支援: Pega の設計標準