システムを作る時#

現代のシステム開発において、まず考えるべきは全体の責務分離である。

システムの複雑性は、個々の機能よりも、各要素の境界設計によって増大することが多い。 そのため、「どこから作るか」よりも「どこを間違えると致命的か」を先に考えた方が良い。

設計上の失敗が後工程に伝播しにくい順序は、概ね次の通りである。

  • 認証・認可
  • バックエンド
  • フロントエンド

以下、順に説明する。

認証・認可#

認証・認可は、システム全体にまたがる横断的な境界である。

一般には「ログイン機能」として認識されがちだが、設計上は「何を信頼し、何を信頼しないか」を定義する部分に相当する。

この責務はバックエンド寄りであるが、外部のIDaaSを利用する場合も多く、フロントエンドとバックエンドの双方に影響を及ぼす。

そのため、最初に設計しておかないと、後続のAPI設計やUI設計に無理が生じやすい。

バックエンド#

バックエンドは、APIを通じてフロントエンドと通信し、業務上の処理とデータの整合性を担う。

ここで重要なのは、設計対象が「ユーザー」ではなく 「ユースケース」である点だ。

その結果、バックエンドは次のような性質を持つ。

  • ステートレス(ログインセッションなどの「状態」を前提にしない)
  • 人間が操作することを前提にしない

UIの都合から切り離して設計することで、APIは再利用性と検証可能性を保ちやすくなる。

フロントエンド#

最後にフロントエンドを設計する。

フロントエンドはユーザーが直接操作する部分であり、体験の質に大きく影響する。

一方で、変更が最も多く発生する層でもあるため、他のレイヤーへの影響が最小限になるよう設計されるべきだ。

認証とAPIの契約が先に定義されていれば、UIは比較的安全に変更・改善を重ねることができる。

次に考えること#

ここまで、一般的なWebシステムにおける設計の順序を整理した。

次に考えるべきは、最初に挙げた「認証・認可」を自分のシステムではどのように定義するか、という点になる。

具体的には、

  • 認証は自前で行うのか、IDaaSを利用するのか
  • 「認証された」とは、システム上どの状態を指すのか
  • フロントエンドとバックエンドは、何をもって信頼するのか

といった点だ。

これらは技術選定の話ではなく、システム全体の前提条件を決める設計の問題である。