はじめに
Outsystemsを使用した開発を進める際、システムの要件をどのようにモジュールやアプリケーションに分化させ構造を設計するのか参考サイトを見ながら自分が読み取れた内容をまとめる。
間違っていたらご助言を...
システムの構成
Outsystemsは1つ以上の「モジュール」で構成される「アプリケーション」という単位で管理される。(LifeTime管理)
Service Studio画面
システムの構造を大きく分割すると上記のModuleとそれを束ねるApplicationで構成される。
Architecture Canvas
OutsystemsではModule/Applicationの機能を3つのレイヤーに分けて整理する方法を推奨している。
このアーキテクチャーフレームワークの名前がArchitecture Canvas
参考：
[OutSystems]Architecture Canvasを使った設計の骨格
アーキテクチャフレームワークを使用したアプリ設計
OutSystemsアプリケーションのサービス指向アーキテクチャ
- システムの構造を3つのレイヤーに分類する
End User：エンドユーザー
再利用しない要素を置く。ユーザーの要求を直接実現する要素を配置する(UI/UX)
Reactive Web Appを配置する
ex：画面UI、再利用しない業務ロジック、Processなど
Core：コアレイヤー
再利用可能な部品で、業務要求に関連するものを配置する。
ビジネスロジック
Serviceモジュールを配置する
ex：Expose API (REST/SOAP)、業務要求に関わるWidget、業務ロジック
Foundation：基盤レイヤー
再利用可能な部品で、業務要求に直接関わらないものを配置する。
Librariesモジュールを配置する
ex：Extension、UI Pattern (OutSystems UI Widget、再利用するUI、Theme)
Moduleの種類
Applicationは1つ以上のModuleで構成されるが、アーキテクチャのレイヤーに従いModuleが持つべき機能が決まる。
またModuleが持つ事のできる機能はモジュールタイプによって決まる。
参考
モジュールタイプ(module type)の違いについて調べる[Outsystems]
【メモ】OutSystemsのアクション差異
以下はモジュールの情報について読み取れたものを表記
Reactive Web Appモジュール
特に機能的な制限がない？
UI 関連の要素を実装するには、リアクティブ Web、モバイル、または従来の Web モジュールを使用する必要がある
End User レイヤーに配置されるモジュール
Serviceモジュール
Serviceモジュールタイプはアーキテクチャ構成におけるEnd Userに属さないモジュールに使用される。
関心事を分離し(DDD？)、カプセル化が必要なCoreレイヤーに適応される。
UI関連の以下の要素を使用することができない。
- UI アセットのモジュール プロパティ (JavaScript、グローバル エラー ハンドラーなど)
- クライアント側ロジック
- ローカルストレージエンティティ
- セッション変数
Librariesモジュール
参考：ライブラリー
以下引用
ライブラリモジュールタイプは、以下の原則を念頭に置いて設計されました。
ライブラリは、ステートレスです。**データベースに情報を保存することやエンティティに直接アクセスすることはできません。
**ライブラリの要素は、コンシューマアプリケーションのコンテキストでのみデプロイされます。**スタンドアロンのアプリケーションとしてデプロイされることはないため、Platform Serverのアプリケーションサーバーの負荷が低減されます。
ライブラリは、それらを参照しているアプリケーションがデプロイされているデータベースに依存しません。
データベースに接続しない画面部品、テンプレートやコンポーネントの考え方に近い。
APIの外部連携機能は使えるので、外部連携部品を作るのに適している。
以下の要素を使用することができない。
- Data(EntitiesやStructureなど）
- InterfaceのScreen要素（Block要素は使用可能）
- Logic内のServer Actionでデータベース操作系の機能（AggregateとSQL)
モジュール間の依存関係のルール
1.上方参照をしない(全レイヤー)
2.側方参照しない(エンドユーザーレイヤー)
3.循環参照しない(全レイヤー)
1.上方参照の問題点
EがAに依存すると、Dの依存に循環が発生する
その結果、Dに依存するBが全モジュールに依存し、認識されていないモジュールで行われた変更による影響を絶えず受ける
2.エンドユーザー間の参照の問題点
最上位のモジュール同士が結合すると、下位レイヤーからの膨大な量の間接的依存をもたらす傾向がある
エンドユーザーが他のモジュールに参照される事はない
3.コア、ライブラリ間で循環しないの例
循環は予期しない影響や管理しにくいコードを伴うため、どのような場合でも望ましくありません。とのこと。
実装されたモジュールがこれらのアーキテクチャルールに従っているかどうかは、Discoveryツールを使用して自動的に確認できます。とのこと。
モジュールの「密結合」「疎結合」
モジュール間の依存関係の中で何の機能を使用するかにより、結合の強さが決まる
強い依存関係：密結合
以下の要素を再利用した場合、コンシューマのプロデューサに対する依存関係は強い依存関係になります。
サーバーアクション
クライアントアクション
ブロック
画像
リソース
スクリプト
テーマ
ロール
プロセス
プロセスアクティビティ
弱い依存関係：疎結合
以下の要素を再利用した場合、コンシューマのプロデューサに対する依存関係は弱い依存関係になります。
画面
サービスアクション
データベースエンティティ
ローカルストレージ
静的エンティティ
ストラクチャ
依存関係を持つモジュールの更新に関わるらしい。(AをPublishするとBが影響を受ける。など)
実際作成しないとよくわからない
まとめ
やってみないと分からないと思ったので、次回はアーキテクチャーのトレーニング動画で例として設計されている診療予約アプリを、実際にPublishするところまでやってみる。