データモデル設計

[Huruikagi]

概要

アプリケーション内でやりとりされるデータの種類と構造をリストアップし、 ドキュメントとして残す。

目的

今後の開発の中で参照する。 Fabricのチャンネル設計とかにも活用される（と思う）。

タスク

• [x] データの種類と構造をリストアップする
• [ ] ER図作成
• [ ] エンティティ一覧表作成
• [ ] エンティティ定義書作成
• [ ] CRUD図作成

[Huruikagi]

wiki/データモデル設計 この辺に書いてね。

[Huruikagi]

日付関係のプロパティをどう表現するか若干難しいな。 通信経路上のJSONの中ではISO 8601で流すことになるんだろうが、サーバー・クライアント・Fabric内の各環境でどのように変換されるのか確認する必要がある。 まあこの段階ではそこまで考えずにDateとしておいたのでもいいけれども。

[Huruikagi]

@Cyberdrgn

1. システムとクライアントという区分がよくわからない。サーバー・クライアントのことか？
2. 今回はOAuthを利用するため、Userのメールアドレスは必須ではない。やっぱりカラムを設けないことにしよう。あとメールアドレスなら email とするのが個人的な好みだ。命名に関しては、必要以上に省略するのは悪だが、冗長になるのもよくない。必要充分な命名を心掛けたい。
3. 所持本のカラムだが、登録日が entryDateTime で削除日が deletedAt というのは命名に一貫性がない。型としてDateTimeを用いないのでカラム名で補足するというのも確かに手ではあるが、個人的には createdAt と deletedAt の方が好み。
4. おなじく所持本のカラムで userId というカラムがあるが、これは owner とした方が意味的に分かりやすい気がする。これのデータ形式は、RestAPIにおけるユーザーのリソースの場所（つまりURL文字列）で表すことにしよう。型としてはStringのままでいい。この理由は、ユーザーIDを「ドメイン名とドメイン内での連番」の組み合わせで一意に特定するため。
5. 貸し借りシステム、という命名は妥当か？
6. 貸し借りシステムの中の lendUserId と borrowUserId は、前述の理由により owner , borrower あたりが良いと思う。
7. 所持本と貸し借りシステムの中の ISBNCode というカラムは isbn でいいと思う。それで伝わる。
8. 貸し借りシステムの中の lendDateTime と returnDateTime も上述の命名規則に修正しておこう。

[Huruikagi]

諸般の事情によりざっくりまとめなおした。