はじめに
最近、「現場で役立つシステム設計の原則」を読んでいるので、本書の中で自分が疑問に感じたポイントをQ&A形式で振り返ってみたいと思います。
この記事では、各セクションの簡単な説明の後に、[Q]で疑問に感じたこと、[A]で調べてわかったこと、そして[NOTE]で覚えておきたいことをまとめています。
なお、サンプルコードにJavaを使用していますが、言語を問わず広く有効な設計手法なので、他言語でも応用できる内容になっています。
第5～6章については、すでに別の記事にまとめているので、こちらもぜひご覧ください！
それでは、第7〜8章を振り返りながら、一緒に「システム設計」について学んでいきましょう！
画面に引きずられた設計はソフトウェアの変更を大変にする
画面アプリケーションのコードが複雑で変更がやっかいになる原因は次の2つです。
- 画面そのものが複雑
- 画面の表示ロジックと業務ロジックが分離できていない
どのようにすれば、画面アプリケーションのコードをわかりやすく整理し、変更を楽で安全にできるでしょうか。
ここでも基本的な考え方は、関心事を分けることです。
画面やプログラムが複雑でわかりにくいのは、異なる関心事がごっちゃになった大きなかたまりになっているためです。
次の方針で関心事を整理すれば、画面アプリケーションの複雑さを改善し、わかりやすく変更が楽で安全にできます。
- さまざまな表示項目やボタンを詰め込んだ何でもできる汎用画面ではなく、用途ごとのシンプルな画面に分ける
- 画面まわりのロジックから業務のロジックを分離する
[NOTE]
注文に関するドメインオブジェクトと注文登録のメソッドは次のように分けて考えることができます。
| 対象 | ドメインオブジェクト | 登録メソッド |
|---|---|---|
| 注文者 | Customer | void register(Customer customer) |
| 注文内容 | Items | void register(Items items) |
| 決済方法 | PaymentMethod | void register(PaymentMethod method) |
| 配送手段 | DeliverySpecification | void register(DeliverySpecification specification) |
| 連絡先 | ContactTo | void register(ContactTo contactTo) |
| 注文の確定 | Order | void submit(Order order) |
ドメインオブジェクトとサービスクラスの登録メソッドを、小さな関心事に分解しました。
この関心事の分離は、画面にも適用できます。
1つの注文登録画面ですべてを入力するのではなく、次のような複数の画面を用意します。
- 顧客の氏名の登録
- 注文内容の登録
- 決済方法の登録
- 配送手段の登録
- 連絡先の登録
- 注文の確定
このように、用途を特定した小さな単位に分けた画面を提供することをタスクベースのインターフェースと呼びます。
タスクベースのユーザインターフェースでは、必要なときに、必要な情報だけを登録できます。
そして、個々の情報を登録するタイミングは、ばらばらでかまいません。
画面の設計方針がタスクベースであれば、画面ごとに必要なドメインオブジェクトとサービスクラスもシンプルになります。
タスクベースの構造にしておけば、タスクごとに独立性の高い開発ができます。
テストも、タスク単位であれば単純になります。
Web APIのしくみを理解する
Web APIを利用する側は約束にしたがって要求を送ります。
Web APIを提供する側は約束どおりに応答しなければいけません。
HTTP通信で連携する場合の基本の約束事は次の4つです。
- 要求の対象を指定する（URI）
- 要求の種類を指定する（HTTPメソッド）
- 処理の結果を伝える（HTTPステータスコード）
- 応答内容の表現形式（JSONやXML）
アプリケーション間で連携する場合、うまくいかなかったときの決め事も重要です。
具体的には、エラー発生時のHTTPステータスコードとレスポンスのデータ内容の設計です。
| コード | テキスト表現 | 説明 |
|---|---|---|
| 400 | Bad Request | 要求が不正 |
| 403 | Forbidden | 要求は禁止されている |
| 404 | Not Found | 要求されたリソースが見つからない |
| 500 | Internal Server Error | エラーが起きたため要求を正しく処理できなかった |
エラーメッセージについては、Web APIで利用側に応答するためのものと、Web APIを提供するサーバ側でログなどに出力するものとは別の内容になります。
Web APIのエラー時の応答メッセージは、APIを利用する側がエラーにどう対応するかを判断する手がかりを提供します。
ここではWeb APIを提供する側の内部の詳細な情報は不要です。
それに対して、Web APIを提供する側で出力するエラーメッセージは、内部のより詳細な情報が必要です。
エラーの原因を調査する重要な手がかりだからです。
[NOTE]
良いAPIは、さまざまなアプリケーションを組み立てるために役に立つことが重要です。
組み立てやすく変更しやすい、適度な大きさに分割した部品が役に立ちます。
| APIの粒度 | 実現できる機能の多様性 | 組み立ての複雑さ |
|---|---|---|
| 小さい | 幅広い | 複雑 |
| 大きい | 限定的 | 単純 |
小さな部品は、組み合わせ方の工夫で実現できる機能が多様になります。
しかし、たくさんの小さな部品を組み立てるコードは複雑になります。
大きな部品は、組み合わせ方が限定されるので実現できる機能は限定されます。
しかし、組み立て自体はかんたんです。
良いWeb APIとは、組み立ての多様性を維持しつつ、組み立ての負担が増えすぎない適切な大きさの部品を用意することです。
おわりに
今回は、「現場で役立つシステム設計の原則」の第7〜8章を題材に、自分が疑問に感じたポイントを紹介しました。
設計を「分けて考える」ことの大切さや、変更に強い構造を意識することの重要性を改めて感じる内容でしたね！
なお、続きとなる第9～10章の記事も公開しているので、ぜひあわせてご覧ください！