システム設計
システムを作る時#
現代のシステム開発において、まず考えるべきは全体の責務分離である。
システムの複雑性は、個々の機能よりも、各要素の境界設計によって増大することが多い。 そのため、「どこから作るか」よりも「どこを間違えると致命的か」を先に考えた方が良い。
設計上の失敗が後工程に伝播しにくい順序は、概ね次の通りである。
- 認証・認可
- バックエンド
- フロントエンド
以下、順に説明する。
認証・認可#
認証・認可は、システム全体にまたがる横断的な境界である。
一般には「ログイン機能」として認識されがちだが、設計上は「何を信頼し、何を信頼しないか」を定義する部分に相当する。
この責務はバックエンド寄りであるが、外部のIDaaSを利用する場合も多く、フロントエンドとバックエンドの双方に影響を及ぼす。
そのため、最初に設計しておかないと、後続のAPI設計やUI設計に無理が生じやすい。
バックエンド#
バックエンドは、APIを通じてフロントエンドと通信し、業務上の処理とデータの整合性を担う。
ここで重要なのは、設計対象が「ユーザー」ではなく 「ユースケース」である点だ。
その結果、バックエンドは次のような性質を持つ。
- ステートレス(ログインセッションなどの「状態」を前提にしない)
- 人間が操作することを前提にしない
UIの都合から切り離して設計することで、APIは再利用性と検証可能性を保ちやすくなる。
フロントエンド#
最後にフロントエンドを設計する。
フロントエンドはユーザーが直接操作する部分であり、体験の質に大きく影響する。
一方で、変更が最も多く発生する層でもあるため、他のレイヤーへの影響が最小限になるよう設計されるべきだ。
認証とAPIの契約が先に定義されていれば、UIは比較的安全に変更・改善を重ねることができる。
次に考えること#
ここまで、一般的なWebシステムにおける設計の順序を整理した。
次に考えるべきは、最初に挙げた「認証・認可」を自分のシステムではどのように定義するか、という点になる。
具体的には、
- 認証は自前で行うのか、IDaaSを利用するのか
- 「認証された」とは、システム上どの状態を指すのか
- フロントエンドとバックエンドは、何をもって信頼するのか
といった点だ。
これらは技術選定の話ではなく、システム全体の前提条件を決める設計の問題である。