OutSystemsにおける高品質な設計のトレーニング（基礎トレ1.5）前編
こんなの現場行ってやれやー！
そう思いつつ朝からアプリを作っている小林である。
今日は高品質な設計のトレーニングです。
私から見ると高品質に見えるのですが、OutSystemsエンジニアから見ると当然なのかもしれません。
ただ、作ってて、バグが出にくいように設計しているのが分かるため、エンジニアはこんなところまで考えてアプリを作っているのかあ～と思いながらアプリを作っていました。
それでは
リンクスタート！！
OutSystemsトレーニング基礎コース1.5の内容は
”1対1の関係を作成して表示
一対多の関係を使ってエンティティを拡張します。”
です。
まあ、作り終わった後に読み返してみても、意味がよく分かりません。このトレーニングの内容は高品質な設計をデータベース上で行って、入力フォームを1本開発することです。
トレーニング動画では
日本語訳：このトレーニングでは、データベースを連結させます。
日本語訳：そして、入力フォームを1本画面に作ります。
ということです。
では、作っていきます。
まずはデータベースを新規に生成し、Diagram（ダイアグラム）にドロップします。
ダイアグラム内では各データベース間のリレーションシップ（連結）が一望できます。
（私の開発画面です。右クリックでデータベースを新規に作って、ダイアグラムの右下にドラッグした図です）
現在の注文書アプリのデータベースは
左上からClient（お客様）→Order（注文）→OrderItem（注文された商品）→Product（在庫）と連結されています。残念ながらこの画面上に日本語は一つも存在しないです。なぜなら、OutSystemsはほとんど日本語に対応していないからです。
今回作った右下にあるデータベースの名前はShippingDetailsです。日本語訳すると「運送詳細」データベースとなります。
それをトレーニング動画ではこのように説明しています。
日本語訳：注文画面に、発送についての詳細情報を追加します。
日本語訳：注文伝票に発送情報を付随させます。
発送情報を注文伝票に付随させるのは当然です。
だって発送されるのは注文した後だから。
なんか、英語だとものすごく難しいのに、日本語訳すると眠たくなるほどに簡単ですね。正直、当たり前すぎて睡くなってきた小林なのであった。
注文がないのに発送して料金を請求するわけにはそらいかんわなと。
そうであるならば、発送（ShippingDetails）データベースを連結させるのは当然ながら注文（Order）データベースになる。
連結させました。
基本的にDiagram（ダイアグラム）は簡単です。
上から見ていくとまずお客様（Client）から注文（Order）が入る。
注文が入ったら、このアプリは注文書アプリなので、右側の配送（ShippingDetails）と左側の注文商品（OrderItem）の両データベースにそのデータが受け渡される。
なぜなら、データが流れて連動しないと在庫の確認と配送先の住所の確認ができないから（これをリレーショナルデータベースと言います）。で、最後に一番左のProductデータベースへ行って、注文した商品の在庫があるかどうかの確認をする訳です。
何を言っているのか分からないけど、ShippingDetailsがOrderとリレーションシップ（連結）するのに外部キーを使わずIdで連結させてしまったから、Idのオートナンバー機能がなくなったということです。
なんで、Idのオートナンバー機能をなくす必要があったのかというとShippingDetailsがOrderデータベースと依存関係がしたかったからです。
なんで依存関係がしたいのかというと、ShippingDetailsが独り立ちして独立したデータベースであってはならないからです。
なんで、独立しちゃいけないのかというと、注文が入った時にだけ発送情報が付随されなければならず、注文が入ってないのに、発送情報だけ独りでに生成されたら、バグになるからです。
あらかじめの設計でバグの出ない設計をしているのだと思います。このトレーニングで言いたいことは、プログラムを書く前に高品質な設計をしなければいけないということです。
今回はあんまり難しくないです。
説明はないけど、独立した外部キーを使ってないからShippingDetailsはOrderの拡張テーブル（意味は分からないけど日本語訳すると「追加表」）であって、連動して削除する機能を盛り込むと説明しています。
それはOrderを削除するときにそれに関連した発送情報がある場合には、その発送情報も自動的に削除され、発送情報だけを単体で削除する余分なコードを追加する必要がないから、とトレーニング動画では説明されています。
が、それ以前の問題として、このやり方だとバグが生まれようがないです。設計の品質を高める書き方のように感じます。
（次のエントリーでアプリを完成させます）
