設計について考える
大枠としては基本設計とDB設計がある
基本設計
要件定義の内容を開発に必要な内容にまとめる
「画面」や「画面遷移の流れ」をまとめていく
そこから実際に書くべきコードを洗い出す詳細設計を行う
要件定義や基本設計の情報をもとに、ユーザーが行う操作に対して行われる処理を全て書き出します。その上で実際どのようなコードを書くか当てはめていく。
Ruby on Railsであれば「ルーティングはどういったものがあるか、対応するコントローラーとそのアクションはどういったものになるか、モデルは ~」といった内容を表にまとめると良いでしょう。
また、画面遷移図という各ページの移動の相関図を作っておくと、チームでの開発での共有や自分のチートシートとしても利用できる
↓画面遷移図の例
DB設計
DB設計とは開発で使用するDBの表を設計することです。具体的には「テーブル」や「カラム」、「アソシエーション」などです。
エンティティ
サービスで扱われるデータ自体をエンティティと言いますが、そのエンティティを洗い出し、それらのテーブル設計とリレーションを考える必要があります。エンティティを考えるポイントとしてはデータが登録されるときに注目すると、わかりやすいです。
モデリング
エンティティの分類や関連付けを行い、模型のように表します。
エンティティを参考にDBを設計する
モデリングされたDBへさらに詳細な設計をしていきます。まずはテーブルの情報を利用しやすい形に変える「正規化」をおこないましょう
正規化
データベースの構造を効率的でシンプルな形にします。
制約について考える
設計の際には入力されるデータに制約をかけることによって、悪質なユーザーの入力や意図しない入力によるエラーを未然に防いでくれます。
Not null制約
t.型 :カラム名, null: falseこのようにテーブルのカラム名の後に書くことによって、null（空欄）の状態で保存されるのを防ぐ機能があります。
一意性制約
テーブル内で重複するデータを禁止する制約です。emailカラムに行えば、同じemailが登録できなくなります。
主キー制約
例としては主に各テーブルのidカラムの項目が主キーに該当します。主キー制約は１、主キーのデータが空になることはない２、重複していないことを保証する。なのでNOT NULLと一意性制約の両方がデフォルトでついています。
また、Railsでテーブルを作成する際、主キー制約はidカラムとして自動で設定されます。
外部キー制約
外部キーとは、関連する他のテーブルのレコードの主キーを値とする項目のことです。
そして、外部キー制約とは、外部キーのデータに対応するレコードが必ず存在することを保証する制約です。
t.references :カラム名, foreign_key: trueこのように設定ができます。ちなみにカラム名にuserと打ち込むとテーブルのカラムにはuser_idと入力されます。
チェック制約
チェック制約は、値が保存される際に条件を満たしているかチェックできる制約です。
たとえば、userのニックネームが6文字以下になるような条件を加えれば、それ以上のニックネームが保存されることはありません。
DBを図で考える
DBのテーブルなどを図で表記したものです。
特徴は、表で記述するよりも関連付けがイメージしやすいことです。