本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。

本日はプレゼンテーション層、いわゆるMVCのViewにあたる部分。

アプリケーション間連携(主にWEBAPIに関して)

要点

• アプリケーション間連携の手法は以下の4つ
  ファイル転送
  〇 歴史があり、比較的単純で容易
  × データのやり取りに関して時間差が発生、ファイル形式を変更しにくい
  データベース共有
  〇 即時性
  ×  セキュリティ的な部分で好ましくない、プログラムが密結合、データベースの変更は影響度が非常に大きい
  WebAPI
  〇 広い範囲でのデータのやり取りが必要、データ連携に関しては事実上、標準規格
  ×  設計の自由度が高く、適切な設計判断が難しい、APIの変更が難しい、同期型なので制約になることが多い
  メッセージング
  〇 非同期なので相手の都合に左右されない
  × 比較的設計が困難
• WEBAPIでは通信方式はHTTP通信、文字コードはUTF8,データ形式はJSONorXML、できることはデータの取得と登録
• 要求対象はURL、要求の種類はHTTP、処理結果をステータスコードで返し、データはJSONかXMLで。
• リソース名はスキーム://ホスト名/リソースへのパスが一般的
  例 https://api.example.com/books/1234
• 要求種類はGET,POST,PUT,DELETE
• GET句ではクエリパラメータを渡して、対象リソースを取得する
• POSTとPUTの違いは事前にデータの仕様を知っているか否か(PUTは知っていなければいけないので密結合になる)
• 一般的にはPOSTのほうがアプリケーション間連携の独立性が高くなる
• DELETEもアプリケーション間の密度が高くなるため、あまりお勧めできない
• パラメータの個数が多かったり、データの項目数が多いものは一般論でいえばアンチパターン
• 基本の設計方針は参照と登録を分ける、リソース(データのかたまり)の単位を分ける
• 例えば登録時のレスポンスで予約内容を返す、を同時に行うと複雑になるため、登録は登録だけ、そのあと別途参照のAPIを使う
• 参照でもデータをうまくカテゴライズ化、階層化する

感想

画面項目を情報の意味でグルーピングするというのは、いろんな本でも書かれていたけど、基本ですね。今の業務アプリも特に注文画面にいろんな情報が詰め込まれており、あれもこれもになってしまっている。

というかデザインだけに限らずあらゆる領域で必要になってくる考え方だと思います。画面の分岐による変更ロジックをドメインオブジェクトの中に組み込む、というのは驚き(本書の中でもかかれていますが・・・)。ようはドメインオブジェクト=関心ごとなのだから、すべてドメインオブジェクトの中に入ってくるだろうということらしいんですね。