以前にこのブログで、APIをどのような観点で設計するかということについて書きました。その際に設計の観点として大きく、DBのスキーマ・画面・ドメインを意識する必要性を挙げました。
今回はDBスキーマの設計、つまりはテーブル設計に少しフォーカスして、APIとの関連について書いてみたいと思います。
まず前提としてテーブル設計にはデータモデリングが必要になり、このデータモデリングは下記の記事にある通り、ドメインモデリングとは異なるという位置付けとします。もちろんドメインモデリングとデータモデリングが被ることは全然あり得ますが、データモデリングの目的はあくまで、データをいかに適切に永続化するか、ということにあるからです。
データモデリングを行った後に個々のテーブル設計を行うわけですが、テーブル設計の進め方については下記の記事が参考になります。記事にも触れられている通り、DBのテーブルは基本的に変化に強くないので、いかに将来の拡張性を見据えて設計するかというのは大事だと思います。また最終的には正規化をするのが基本なので、重複や不整合が無いような設計にするのも大事でしょう。
システムが対象にする業務が複雑では無い時、例えば画面においてもCRUDが出来れば良いというケースであれば、画面≒テーブル定義≒ドメインとなると思います。APIもテーブルのフォーマットに合わせれば、ほぼ問題ないでしょう。ただ、業務が複雑になってくるとそうはいかなくなります。
テーブル設計の観点は上記で書いた通り、業務をいかにデータに残すかに加えて拡張性や正規化などを加味した結果です。ドメインはあくまで業務が対象とする領域を表現したもの、画面については画面を触るユーザの関心事が主になります。この3者がズレていた場合、一致させるというのも一つの手ではありますが、要所要所でどれを優先させるかというのがやはり現実的かなとは感じます。
では、この3者がズレていた場合APIはどうすれば良いか。もちろんテーブルのフォーマットにAPIを合わせるというやり方は分かりやすいですが、APIの利用者が必ずしもそれで使いやすいという状況にもならないでしょう。現実案としてはAPIの利用ケースによって、どこに合わせるかはその時々で判断するというのが、落とし所になるかなとは感じます。
とはいえ、バックエンドで全てのケースに対応したAPIを用意するのは、非効率になるかもしれません。なのでGraphQLなどを利用して、BFFを別途立てるという選択肢もありかなとは思います。
