はじめに
Outsystemsのアーキテクチャ設計について記事を作成したが、実際にアプリを作成しないとよく分からないと感じた。
前回の記事：【Outsystems】モジュール・アーキテクチャ設計について
公式トレーニング動画に「診療予約アプリ」の仕様をArchitecture Canvasで設計に落とし込むチュートリアルがあったため、そのアプリを実装しながら設計についての理解を進めたいと思った。
参考：アーキテクチャフレームワークを使用したアプリ設計
まとまった内容でなく、また後半感想文になってしまったが記録として…
要件を書き出す
チュートリアル動画の中で要件定義を行っていたが、あまり具体的に定義されていなかったため自分の中で補足しながら作成するアプリケーションの機能をまとめる。
概要
病院で医師の診療予定を管理するシステムを作成する。
事務員はお問合せ内容から診療予定を作成する。
医師は診療予定を確定し自分のGoogleカレンダーに追加する。
患者は自分のアカウントを登録しログイン後に患者用フォームから診療のお問合せをする。
医師と事務員は管理者側のサイトURLからアクセスする
医師は
- 医師としてログインする
- 診療予定の一覧を見る
- 診療予定の詳細を見る
- 診療予定を確定/キャンセルする
- 確定した診療予定を自身のGoogleカレンダーにイベントとして登録/削除する
事務員は
- 事務員としてログインする
- 患者からのお問い合わせ一覧を見る
- お問い合わせから各医師の診療予定を作成/削除/編集する
患者は
- アカウントの新規登録をする
- 患者としてログインする
- フォームから診療予約を
アーキテクチャに配置する
こちらは動画に各機能を細かく切り分けた際、下記のようなアプリケーションが作成されると考えた。
End-User-Applicationがそれぞれユーザーに機能を提供するために共通パーツであるCoreアプリケーションやライブライを参照する。
設計思想に反した形で作成した
アーキテクチャの重要性を理解するため、最初は設計思想に反して全ての機能を詰め込んだモジュールや単一のアプリケーションを作成し、後から設計図通りの形に分離しようと考えた。
DoctorPlannerというアプリケーションにモジュールを１つ作成し、そこにほとんどの機能を詰め込んだ。
またルートURLを分けるためだけにPatientアプリケーションを作成し、そこに一部患者に関するロジック、患者用の画面を設置した。
設計を無視して作成した感想
今までのシステム開発設計におけるメリット、デメリットとほとんど同じ事を感じた。
参考：ソフトウェアアーキテクチャとは？重要性や種類を分かりやすく解説
その中でOutsystemsに特徴的な内容を記載する
設計に配慮しなくてもそこまで可読性が下がらない
Outsystemsではコードの記述量が少なく、開発ツールのServiceStudioでアプリを作成するため、あまり意識しなくてもロジックが整理される
例えば医師が診療予定とGoogleClendarのイベントを見ながら、自分のGoogle calendarに診療予定を追加する下記画面について
DBからのデータ取得の処理やGoogle calendarのAPIに関する処理など、コードをファイルで管理する既存の方法では複雑になりやすいが、
Outsystemsでは画面、UIに直接紐づくClientアクションや主要な処理を行うServerアクションに分類されており、特に設計を意識しなくても構造化される。
またCRUDやFetchがEntityに紐づくロジックとして既に作成されているため簡単なアプリであればロジック自体の記述量も増えない
全ての機能を単一のモジュールに詰め込んでも簡単なアプリのため、ロジックの数自体はそれほど多くならなかった
Entityに紐づくCRUDがすでに用意されている
モジュールに分割しないと共同開発できない
Publishの単位がモジュール単位のため、また既存のシステム開発と異なり、Gitなどのバージョン管理ができないため、共同開発を行うためにどのようにモジュールを分けるか考える必要があると感じた。
依存関係を整理してモジュールに分割しないと影響を受け続ける
今回、2つ目のアプリケーションであるPatient AppがDoctor Appに完全に依存している形であるため、Doctor Appの変更の度にPatient App内で依存性の更新を促すアラートが鳴った。
これはアンチパターンとしてエンドユーザーレイヤー間の参照で説明されていた。
AがBに依存するアンチパターン
変更が容易である
この点が一番強く実感した。
アプリを作成しながらEntityのカラム変更や認証Roleの再設定など、かなり大きな変更をしたが、既存のリファクタリングほど手間がかからなかった。
まとめ
今回、Architecture Canvasの概要を掴むため簡単なアプリをまずは設計を無視して実装した。
機能的な面を実装する分には慣れもあり困らなかったが、共同開発をする際などは機能を分割してモジュールを作成していく必要があると感じた。
後半ほとんど感想になってしまったが、次回は最初の設計にもとづいてアプリケーションを適切に分割しOutsysmtesにおける設計の概要を掴みたい。