[OutSystems] シン・とりあえず Reactive なプロジェクトにはこれ導入しておくと良い規約

とりあえず Reactive なプロジェクトにはこれ導入しておくと良いって規約の"シン"版です

1. シン・とりあえず Reactive なプロジェクトには これを導入しておくと良い規約 片野 潤一 伊藤忠テクノソリューションズ アジャイル営業推進部 Photo by Isaac Smith on Unsplash
2. 片野 潤一 かたのじゅんいち/かたじゅん 伊藤忠テクノソリューションズ（略称：CTC） 主業務 ローコードプラットフォーム： OutSystems の推進 - プリセールス、技術支援 - トレーニング講師、講師育成 @kata_junn kata_junn 社内活動 - 社内 OutSystems Developer 向け勉強会開催、登壇 - Webinar 企画、登壇 社外活動 - OutSystems User Group、Qiita、セミナー登壇 資格系 - OutSystems 資格全部、Certified Scrum Master、等 ティアキンまだやってます
3. 3 Traditional だよ！ 今やってるプロジェクトは… Reactive だよ！ OutSystems やったことないよ！
4. 今日の話が響きそうな属性 Reactive なアプリケーションを実装している これから Reactive なアプリケーションに関わりそう Traditional はもう飽きたな、Reactive したいな OutSystems の規約ってどんなのか興味がある 4
5. Façade Action
6. 6 “Facade（ファサード）とは「建物の正面」を意味す る。異なるサブシステムを単純な操作だけを持った Facadeクラスで結び、サブシステム間の独立性を高め る事を目的とする。 Wikipedia https://ja.wikipedia.org/wiki/Facade_%E3%83%91%E3%82%BF%E3%8 3%BC%E3%83%B3
7. Screen Action Server Action 画面機能を実現するための主役たち
8. Screen Action Server Action 画面機能を実現するための主役たち
9. Screen Action Server Action 画面機能を実現するための主役たち
10. Screen Action Server Action 画面機能を実現するための主役たち Screen Action から Server Action 呼び出しは 1 回以下
11. Screen Action Server Action
12. Façade Action
13. 13 “Facade（ファサード）とは「建物の正面」を意味す る。異なるサブシステムを単純な操作だけを持った Facadeクラスで結び、サブシステム間の独立性を高め る事を目的とする。 Wikipedia https://ja.wikipedia.org/wiki/Facade_%E3%83%91%E3%82%BF%E3%8 3%BC%E3%83%B3
14. 14 “Facade（ファサード）とは「建物の正面」を意味す る。異なるサブシステムを単純な操作だけを持った Facadeクラスで結び、サブシステム間の独立性を高め る事を目的とする。 Wikipedia https://ja.wikipedia.org/wiki/Facade_%E3%83%91%E3%82%BF%E3%8 3%BC%E3%83%B3 いろんな処理を捌いてくれる執事
16. Screen Action Server Action
17. Façade Action Screen Action Server Action
18. Façade Action の具体的な規約 ⚫ Screen Action と 1:1 の Façade Action を作る ⚫ フォルダ/Action 名 ⁻ ServerActions -> [Screen 名] ⁻ [Screen 名]_[Screen Action 名]Facade ⁻ ex. HogeDetail_SaveFacade ⚫ 他細かいの ⁻ Façade Action → Façade Action 呼び出し禁止 ⁻ Server Action → Façade Action 呼び出し禁止
19. Façade で EU 内をレイヤードアーキテクチャ化 Screen Action Façade Action Server Action 依存の方向 再利用性 画面機能に特化したサーバーサイドロジック 共通ロジックのオーケストレータ ※同層（他の Façade）呼び出し禁止 共通ロジック ※同層（他の Service）呼び出し OK でも循環には気を付けよう 画面機能に特化したクライアント処理 バリデーションや UI ロジック 対応する Façade を呼び出す。時には再利用されることも。 △ × 〇
20. Façade Action の責務 ⚫ 画面機能に特化したサーバーサイドロジックの実装 ⁻ 共通ロジックに切り出す必要がないロジックを実装 ⚫ 共通ロジックのオーケストレータ ⁻ 共通ロジックへのパラメータ授受 ⁻ 呼び出し順序制御 ⁻ エラーハンドリング
21. Façade Action を設ける利点 ⚫ Screen Action の品質一定化 ⁻ Screen Action が呼び出す Server Action が明確になる ⁻ 規約に従うと Reactive 実装ベストプラクティスが遵守できる ⚫ 実装責務の明確化 ⁻ Screen Action、Façade Action、（非 Façade な）Server Action ⁻ 副次的に影響範囲の局所化
22. まとめ × FAQ
23. まとめ ⚫ Façade Action を設けてレイヤードアーキテクチャ化しよう！ ⁻ Reactive 実装のベストプラクティスに則ることができる ⁻ Screen Action/Façade Action/Server Action の責務を明確にできる ⚫ 具体的にどんな実装になるの？
24. Data Action に対応する Façade Action は作るの？ ⚫ Data Action 自体が Façade と似た責務を持つので、Façade を作っても アーキテクチャ観点では利点が少ないです。 ⚫ ただ、ユニットテストを書いているプロジェクトであれば別です。Data Action はテストできないが Façade はテストでき、かつ Facade はきち んとテストされるべきだからです。
25. Façade のユニットテスト、すごく大変そう… ⚫ OutSystems 公式の BDD Framework を使用するとすごく大変です。 Façade がちゃんと動くための前提条件を整える必要がありますが、 BDD は Public な Action しかテストできないのと、Mocking に弱いの で呼び出す全ての Action を把握し、事前データ準備もすべて行ってお く必要があるからです。
26. Façade のユニットテスト、すごく大変そう… ⚫ Façade の本質は”オーケストレーター”と”固有ロジック”であり、依存先に 興味はありません。が、 BDD だと把握しなければなりません。 ⚫ そんな状況を救い得るのが Testing Framework。非公式だけど最高！ Forge：https://www.outsystems.com/forge/component-overview/12754/testing-framework 紹介スライド：https://speakerdeck.com/kata_junn/outsystems-testing-framework-gaii-totemoii
27. 複数の Screen Action で同じ Façade を使ってもいい？ ⚫ 良いです。ロジックによりそういったことはあり得るでしょう。 その場合、Façade には使用される Screen Action の名前を全て含める とわかりやすいと思います。 ex. HogeScreen_Save_SaveAndNext_Facade
28. ご清聴ありがとうございました ご質問があれば お願いします！