アーキテクチャ特性

アーキテクチャとは？

• ドメイン機能に直接関連しないが、ソフトウェアとして満たす必要のある要件
• アーキテクチャ特性を「定義」・「発見」・「分析」すること

アーキテクチャ特性とは？

• 「非機能要件」に当たる
• 非要件機能とは、システムの品質や特性を表すもので、運用を行ううえで決定すべきこと（システムがどのように動作するか定義する）
  • セキュリティや性能（どの程度のアクセスに耐えれるか、どの程度のユーザーを想定するか、継続性）

アーキテクチャ特性はトレードオフ

• 全ての要件を取り込むことはできない。
• セキュリティを担保しようとすると、パフォーマンスは低下します。
  • 何かしらの処理を実行しようとする時、セキュリティを担保することにより間接的に認証ロジックを参照することとなる。
    実行ボタンクリック -> 認証ロジック -> 実行処理となります。
  • 上記においては、誤差の範囲かもしれませんが、少なくとも実行速度はセキュリティを担保していない時に比べて劣ります。

どのように選定するのか

アーキテクチャの特性を明らかにするには、ドメインの問題を理解する必要がある。

暗黙的な特性

下記の特性については、最低限全てのシステムで必要となるアークテクチャ特性

1. 可用性 → サイトに確実にアクセスできることを担保すること。
2. 信頼性 → ユーザーがサイト・アプリケーションとやりとりしている間サイトが稼働し続けていることを担保すること。
3. セキュリティ → 担保する必要のある特性ではあるが、求めるセキュリティのレベルによって優先度をつけることが可能。

上記の特性に沿って例をみてみる。
1及び２に関してはなんとなくイメージがつくと思うので３について考えてみます。

例1 :サードパーティライブラリへの接続情報を管理

上記に事例については、サードパーティライブラリへ接続する際は、秘匿情報としてアプリケーションと:サードパーティライブラリを接続情報となる情報があります。
これらはセキュリティ面で考えると、保持する情報としては重要なものであり、第三者が取得できてしまうとサードパーティライブラリに接続が可能となります。

そのため、上記の接続情報を管理する優先度はために設定されるかと思います。

例2：決済回りの管理について

ECサイトのような決済が必要となる場合において、決済情報（クレジットカード情報・氏名）を下記の２パターンで管理することが多いです。

• 自前で決済を実装

この場合だと、決済情報を自前で管理する必要があるため、セキュリティの優先度は一番高いものなる

• サードパーティライブラリを用いて決済を実装する

決済周りのセキュリティはサードパーティライブラリを用いることで、決済情報の管理はそちらの方にセキュリティ担保委譲できるため、セキュリティの優先度を下げることができる。

参考

• https://products.sint.co.jp/ober/blog/nonfunctionalrequirements#toc-1
• https://zenn.dev/nakaryo/articles/0e6b53d4eeeca2