OutSystemsで作るEntityはテーブル定義とプリミティブなCRUD操作をパッケージしたもの。
このEntityの更新処理を1箇所（特定のeSpace）に閉じ込めることで、権限チェック／バリデーション／ログ出力／計算／共通列の設定が確実に行われるようにする設計パターンが、Core Entity Pattern。
このパターンに従っていないと、Architecture Dashboardの指摘事項に挙がってしまう。
詳細はコード解析パターンの「パブリックエンティティが読み取り専用でない」を参照。
確認環境
Personal Environment(Version 11.14.0 (Build 33133))
Service Studio (Version 11.14.3)
概要
以下の、CoreモジュールがCore Entity Patternの実装。
- CoreモジュールにEntityを定義する
- Entityは参照のみ公開設定
- Entityを更新するためのActionを公開設定で作成する
- Consumerは、検索はEntityに対するAggregateで、更新は公開されたActionで行う
設定方法
Entity
「Entityは参照のみ公開設定」の実現方法：
- EntityのPublicプロパティ=Yes → 他のモジュールから参照可能になる
- EntityのExpose Read Onlyプロパティ=Yes → 他のモジュールからは、Entityに対する更新処理（SQL要素による更新や更新用Entity Action）を使えなくなる
この設定をしたEntityを参照すると、以下のような見た目になる。
（更新系のEntity Actionが全て表示されない）
Action
一般的にはServer Action。
Public=Yesにする。
実装例
あくまで例として
- ログ出力
- 権限チェック
- バリデーション
- 共通属性設定
を含めたものは以下のようなイメージになる。
環境内のProduct Entityに対する更新が、全てこのActionを呼ぶことによって問題発生時に見るべき場所、保守対応時に修正すべき場所を一箇所にすることができる。
外部DBの場合の注意
外部DBのEntityはPublicやExpose Read Onlyプロパティを変更できない（すべて公開になる）。
Core Entity Patternを完全に強制することはできないということ。
仕方ないので、標準として、「更新処理はCore Entity Patternにしたがって実装する。該当モジュール以外での直接の更新は禁止」としてレビューで検出する。
参考資料
公式ドキュメントでは見つからず。
公式動画はあった。
Architecture Patterns in OutSystemsの4分あたりから。