本記事について
本記事では、とある企業の1dayインターンに参加し、サーバーサイドの設計周りについて学んだことをアウトプットしていきます。
内容
1グループ（3名）＋メンター（1名）の構成でグループメンバーと議論しながら、モブプロ形式で設計を進めていきます。
大まかな手順は以下の通りです。
- 要件の整理
- ER図の作成
- APIエンドポイントの設計
要件の整理
要件の内容は、飲食店の注文システムの構築です。
以下の観点を探りながら、要件を理解していきます。
- 利用シーン（飲食店の注文システム）
- どのユーザが利用するのか
- どのような機能が必要になるのか
要件の理解を深めた後、グループでいくつかの観点に対してキーワードを挙げて、重要なキーワードを可視化しました。
具体例には、以下の通りです。
ER図の作成
ER図の作成メリット
データベース構造を整理して、システム全体の構成を俯瞰することができるため、手戻りの発生を減少させることが可能です。
大規模になると、Table数が膨大になり、システム全体が複雑化します。
整理せずにデータを増やしていくと、徐々にデータの不整合が発生し、プロジェクトに大きな損害を与えてしまいます。
長期的にプロジェクトがスケールしていくことを想定すると、事前にER図を作ることは必要不可欠だと考えます。
所感：
iOS開発（どの領域でも同様）でも、全体把握やクラス間の関係性を可視化するため、クラス図を作成します。iOSなどのフロントエンドの開発だと、クラス図を作成する人が少ない印象ですが、DBの場合は必ず作成しないといけないと危機感を感じます。
ER図作成フロー
以下の手順で行いました。
- イベント系エンティティ
- リソース系エンティティ
- エンティティの項目
- リレーションの設定
dbdiagram.ioというツールを用いて可視化しました。
メンターさんにもレビューを受けながら、最終的に作成したER図は以下の通りです。
APIエンドポイントの設計
概要、HTTPメソッド、エンドポイントの観点でエンドポイントを洗い出しました。（今回はREST APIにしています）
設計時に意識した点は以下の通りです。
- 人間がわかるURLすること
× http://fuyan.example.com/u/d
→ uとdは何を示しているかわからない
○ http://fuyan.example.com/users/details
- 冗長にせずシンプルに
× http://fuyan.example.com/fuyan/users
→ ドメインとパスが被っている
○ http://fuyan.example.com/users
- サーバの実装に依存しない
× http://fuyan.example.com/cgi-bin/users.php
→ セキュリティの観点から内部実装を知られてはいけない
○ http://fuyan.example.com/users
一通り洗い出した後、どのエンドポイントが必要なのか、不必要なのかといった観点でグループ議論を行いました。
グループ議論の中でどのロジックをフロントエンドに任せるかという議論がありました。
そもそもフロントエンドは基本的にViewを表示するロジック（プレゼンテーションロジック）に責務を持ちます。特に今回はビジネスロジックに近い内容だったため、バックエンド側で持つべきだと判断しました。
学び
ER図の学び
- 全体像の把握としてER図の作成は必須
- DB：データに責務、バックエンド：ビジネスロジック責務を持つ
- セキュリティ面や、ドメイン知識、利用シーンのイメージ力の必要性
- 大規模になるとモノリスや、マイクロサービスの話につながってくる
- データの不整合は間違ったロジックで実装された時に発生
API設計の学び
- エンドポイントはフロントが理解できるレベルに落とし込むことが必要
- どこまでAPIとして実装するかは周りの環境やリソースに依存
- パラメータの設定基準
- パスパラメータ ：特定のリソースを識別
- クエリパラメータ：検索やフィルタなどの条件
- リクエストボディ：追加・更新が発生するもの、上記のパラメータが増えていきそうな場合など
課題
ER図を作成する中で、エンティティ項目を洗い出し、リレーションの設定が非常に難しいと感じました。粒度や判断基準などは経験を積んで感覚を掴みたいです。
またAPI設計の際、ユースケースと機能の洗い出しから始めた方がスムーズだと思いました。
最後に
自分はサービス主体で開発を考える人間（いわゆるサービス志向）ですが、それはフロントエンドのみユーザとの距離が近いことが関係していると考えていました。しかし、実際にDBやAPI設計を行う中で、フロントエンド開発者の開発体験の考慮や、ユーザが安全に利用できる仕組みなどを考え、サービス志向で開発することができることを実感しました。
今後は実装に着手してパフォーマンス周り、キャッシュなど開発体験の向上につながる技術を学びたいと思います。
拙い文章でしたが、皆さんの参考になれば幸いです。
参考
ER図のコード
// Creating tables
Table orders {
id int [pk, increment] // auto-increment
table_id int [ref: > seats.table_id]
is_served bool
}
Table orders_item {
id int [pk, increment] // auto-increment
orders_id int [ref: > orders.id]
menu_id int [ref: > menu.id]
menu_amount int
}
Table menu {
id int [pk, increment] // auto-increment
restaurant_id int [ref: > restaurants.id]
name varchar
price int
image_url varchar
}
Table restaurants {
id int [pk, increment] // auto-increment
name varchar
}
Table tables {
id int [pk, increment] // auto-increment
restaurant_id int [ref: > restaurants.id]
}
Table seats {
uuid int [pk, increment]
table_id int [ref: > tables.id]
}
``