📜

【詳細設計】アプリケーション詳細設計の作成

2023/07/13に公開

テーブル定義書が終わり、アプリケーション詳細設計を作成する。
回答にならないよう、悩んだところのみの備忘録を残します。

詳細設計とは

基本設計：画面設計、データベース設計、ER図、テーブル定義書（For ユーザー）
詳細設計：基本設計でまとめたものをどのように実装するか決めること（For エンジニア）

システムやアプリケーション仕様や機能を具体的に定義し、設計するプロセスのこと。つまり、アプリケーションを作る前に必要な「設計図」。

開発現場ごとに作成する書式は様々だが、スクールでは、Controller、Model、Routingを記載する。

以下の表のとおり。

必要性	説明
効率的な開発	開発プロセスを効率化し、作業の重複や無駄を減らす
一貫性の確保	一貫性のある設計やコーディングを実現し、バグや不具合を防止
コミュニケーションの円滑化	開発チームや関係者間のコミュニケーションを円滑にする
変更への対応	変更や拡張が容易に行える設計を行い、柔軟なシステムを構築
品質向上とバグの予防	品質の向上を図り、バグやエラーの発生を予防する

以下の通り作成していく。

顧客の登録情報確認画面：
Deviseのgemを使うので、/customers/editを使用すると、Deviseの編集ページと重複する。明確化のため、/customers/information/editとする。
注文情報確認画面：
入力した注文情報のデータを送信するため、HTTPメソッドは「POST」を使用。

GET vs POST

HTTPメソッド	説明
GET	サーバーからデータを取得
POST	サーバーにデータを送信

イメージとしては、
GET：ウェブページのリンククリック
POST：フォームの送信

注文確定処理：
アクションは「create」を使用。注文入力画面（「new」アクション）で入力した注文データを、注文確定時データベースに保存するので「create」が適切。

注文詳細画面にordersコントローラを使用：
注文の情報（注文ID、日時、配送先、支払い方法など）は親の情報。
注文詳細の情報（商品名、個数、製作ステータスなど）は子の情報。
今回実装する注文詳細ページでは、注文情報の内容を含んでいるので、注文IDを基準として親の情報（注文情報）と子の情報（注文詳細情報）を表示させる。
つまり、次のようなURLを作れる。/admin/orders/:id

穴埋め形式問題だったけどなかなか難しかった。
チームで意見を出しながらまとめることで完成！明日は工程表の完成とgitの練習！
順調に実装に入れるかな？