はじめに

CodeIgniterを利用したWebサイト開発に携わった際、サイトに表示するデータの取得方法をめぐって設計レビューで議論になったことがあります。

当時の私は、「必要なデータはDBにあるのだから、直接取得すればいいのでは」と考えていました。ところがレビューで指摘を受けるうちに、実装コストだけでなく、保守性やシステム間の責務についても考えさせられることになりました。この記事では、そのとき学んだことを振り返ります。

背景

担当していた案件では、サイトに表示するデータを別システムから取得する必要がありました。方法としては、DBを直接参照するか、APIを経由して取得するかの二択です。

当時の私は開発スピードを優先して、DB直参照でいいだろうと考えていました。理由は単純で、API開発が不要な分、SQLを書けばすぐにデータが取れますし、実装工数も少なく、動作確認もしやすいからです。開発者目線では、最短距離で機能を実現できる方法に見えていました。

レビューで指摘されたこと

設計レビューでまず挙がったのは、DB構造変更の影響を直接受けるという点でした。DBを直接参照していると、提供元システムでテーブル名やカラム名が変更された場合、利用側の改修も避けられません。

システム間の結合度が高くなるという指摘も受けました。利用側がテーブル構造を前提に実装することになるため、システム同士の依存関係が強くなり、将来システム構成を変えたいときの障害になりかねないという話でした。

もう一つ印象に残っているのが、データ提供の責務が曖昧になるという指摘です。利用側が直接DBへアクセスする形だと、「どのデータを外部へ公開するのか」という線引きがあいまいになります。APIであれば、公開するデータを明確に定義できます。

最終的にAPI経由を選択した理由

議論の結果、API経由で取得する方針に決まりました。データ提供の責務を明確にできるうえ、DB構造も隠蔽できます。将来的な変更が起きても影響を小さく抑えられますし、他システムからも再利用しやすくなるというメリットもありました。実装工数だけを見ればDB直参照の方が有利でしたが、長期的な保守性を考えるとAPI経由に分があると判断されたのです。

振り返り

当時の私は、「実装しやすいかどうか」という視点でしか物事を見ていませんでした。実装コストが大事なのは間違いありませんが、設計判断ではそれだけでは足りません。今回のレビューを通じて、保守性やシステム間の責務、将来の変更容易性、結合度といった観点も併せて考える必要があることを学びました。

おわりに

DB直参照とAPI経由、どちらが常に正しいというものではありません。今回の案件では長期的な保守性と責務分離を重視し、API経由を選ぶ判断になった、というだけの話です。同じような議論に遭遇したときの参考になれば幸いです。