書籍「アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築」のメモ
随時更新します。
https://gyazo.com/80759d1e107beee40358a3a10361c0e6
アーキテクチャ
定義
システムを成り立たせる基本的な考え方・構造・原則の集合体のこと。
アーキテクチャの四つの側面
1.アーキテクチャによって達成すべきこと
2.設計判断
3.システムの形状
4.文書・規約・ガイドライン
アーキテクト
定義
会社のIT戦略を実現するために、以下を行う人のこと。
システム全体の「構造（どんな仕組みで動くか）」を設計する
開発に必要な「要件（何を作る必要があるか）」を整理する
「システムの方式（どう作るか・どんな技術を使うか）」を決める
その開発をリードし、チームを指導する
備えるべき能力
設計力、コーディング力
抽象化能力
ビジネスの理解
好奇心
完璧主義よりも合理主義
ビジネス環境において、2種類のスピードが大事
市場投入までのスピード
MVPを市場に出した上で、顧客の反応を見ながら軌道修正を行うアプローチを取る。 変化に対応するスピード
細かな軌道修正を繰り返して、顧客ニーズが満たされる状態を目指す。
変化への対応を容易にするためには、ソフトウェアの内部品質を高めるための、一貫した方針や仕組みが必須。
ソフトウェア開発のプロセス
要求分析
設計
実装・テスト
ソフトウェア設計
設計の抽象レベル
四つの抽象レベルに分けられる
アーキテクチャ設計
モジュール設計
コンポーネント設計
クラス設計
設計原則
以下の原則を活用すると良い
二種類のロジック
ソフトウェアの振る舞いを実現するコードは、中核ロジックと処理フローロジックの二種類に分けることができる
アーキテクチャ設計
アーキテクチャドライバの特定
アーキテクチャを検討する上で重要な考慮事項のこと
項目例
制約
ビジネス上の制約
技術的な制約
品質特性
影響を与える機能要求
その他の影響を及ぼすもの
システムアーキテクチャの選定
システム全体をどのような責務を持つサービスに分割し、それらがどのような方式で連携するかを定める。以下の三つの事柄について検討する。
構成要素への分割方法
各構成要素への責務の割り当て
構成要素同士の相互作用
ポイント
アーキテクチャの選定はトレードオフであること
あらゆる品質特性に置いて百点満点を取ることは不可。それを認識すること。
アーキテクチャパターンを活用する
検討例
モノシリックアーキテクチャと分散アーキテクチャ
アプリケーションアーキテクチャの選定
システムを構成する各々のサービス（アプリケーション）に対して、上記三つの事柄について検討する。つまり、アプリケーションをどのような責務を持つサービスに分割し、それらがどのような方式で連携するかを定める。
どのアーキテクチャスタイルを採用するのか決める
アーキテクチャの文書化
個々の設計判断を記録して共有することが目的。
以下を含める
目的
アーキテクチャドライバ
システム全体構成
アクターとステークホルダー
アーキテクチャモデル
アーキテクチャモデルをステークホルダーの関心事に合わせて適切に表現するためのビューポイントセット
4+1ビュー
C4モデル
アーキテクチャ実装
開発プロセスの全体像
1.開発プロセスの標準化作業
仕様書、設計書、規約類などの入力情報の準備
作成ドキュメントの種類と作成タイミングを決める
成果物レビューや承認方法などのプロセスを決める
開発環境セットアップや実装作業を支援するためのガイドライン
2.構成管理の方針を決める
ソースコードをビルドして解析やテストを行った上で環境へデプロイする一連のプロセスはCI/CDツールを利用して自動化すべきである。
そのあたりのツール選定なども含めて検討する。
ドキュメントの標準化
ユースケース図
アクターとユースケースとの関わりを俯瞰する目的で作成する。
ユースケース記述
個々のユースケースに対して振る舞い要求を仕様としてまとめたもの。
機能仕様書
ユーザーインターフェースとなる画面や帳票の仕様をまとめる
項目例
画面遷移図
画面レイアウト定義
項目定義
画面イベント定義
ロジック定義
設計書
基本的には、プロジェクト次第
一方、必ず作ったほうがいい設計書もある
ER図
テーブル一覧
テーブル定義書
ユースケースの選定
アプリケーション機能として特定のユースケースを実装しながら必要な共通機能を取り揃えていく戦略が効果的。
サンプルのユースケース または リアルなユースケース を選定する
ユースケースの実装
選定済みのアプリケーションアーキテクチャ、アーキテクチャスタイルをベースにコンポーネントの配置や相互作用を検討する。
アプリケーション基盤の実装
共通機能の例として以下が挙げられる。
認証
認可
セッション管理
エラーハンドリング
ロギング
セキュリティ
トランザクション制御
データベースアクセス
国際化
帳票出力
キャッシュ気候
非同期処理
アプリケーション開発の準備
各種ドキュメントを整備する必要がある
開発規約
手順書
実装参考資料
構成管理
管理対象の資材は以下の通り
ソースコード
テストコード
テストデータ
設定ファイル
ビルドスクリプト
データベース資材（DDLやDML）
CI/CD
デプロイ可能なモジュールをビルドするプロセスや、実際に環境へリリースないしデプロイするプロセスを自動化する仕組みを構築する
品質保証とテスト
アーキテクトと品質保証活動
品質保証（QA: Quality Assurance）
システムが期待される品質基準をクリアし、顧客や利用者のニーズを満たすようにするための活動全般を指す。
テスト
開発したソフトウェアが仕様どおりに動作することを検証する行為を指す
適切なレビューの実施や、解析ツールの導入、開発プロセスやドキュメントの標準化など、品質を向上し維持し続けるために必要なあらゆるアプローチを包含するもの。
シフトレフト
テストを始めとする品質保証の活動をより早い段階、すなわちソフトウェア開発の上流工程から実施し、不具合の発見と修正を早期に行うこと
修正コストを抑制するのが狙い。
様々な品質保証活動を早期から実施するアプローチ。単に早い段階からテストを開始するというものではない。
テストタイプ
table:品質特性とテストタイプ
品質特性 テストタイプ
機能適合性 機能テスト
性能効率性 パフォーマンステスト
互換性 システムテスト
使用性 ユーザビリティテスト
信頼性 運用テスト
セキュリティ セキュリティテスト
保守性 静的解析
移植性 インストールテスト、バージョンアップテスト
テスト戦略
何のテストをどのタイミングでどのように実施するか、また、プロジェクトの資源をどう配分するかなどの全体的な方針策定を指す。
テストレベル
テスト実施対象のソフトウェア構成要素の粒度や範囲、あるいは開発のアクティビティや工程などの観点で、テストを段階分けする概念。
「単体テスト」「結合テスト」「システムテスト」などが具体的なテストレベルの例。
「単体テスト」という言葉を1つ取っても、人によってイメージするものが異なるため注意する
プログラム単体のテスト
機能単体のテスト
テストタイプ
テストの具体的な目的や、評価と検証を行う観点によってテストを分類する概念。大きくは機能テストと非機能テストに二分される。細かく分類すると、「品質特性とテストタイプ」のよな複数のテストタイプに分類可能。
テスト環境とテストデータ
テスト自動化方針
機能テストの自動化
テスト戦略
ユニットテスト、インテ―グレーションテスト、E2Eテストの順に作成する自動テストの量を少なくしていく。
パフォーマンステスト
table:パフォーマンステストのテストタイプ
テストタイプ 概要
単機能性能テスト 個々のオンライン機能やバッチ機能を単体に動作させた場合に、所定の時間内に処理が完了することを検証する
負荷テスト 想定されるピーク時の負荷をかけた状態で、システムが所定のスループット及びレスポンスを達成できることや、システムリソースが効率的に利用されていることを検証する
ロングランテスト システムを長時間連続で稼働させたときに、継続して安定したパフォーマンスが出ることを検証する
スケーラビリティテスト システムに対する負荷の増加に対して、リソースの増強や構成変更などの拡張を行うことで、柔軟に適応可能であることを検証する。
単機能性能テスト
テスト対象機能の選定
性能目標値の設定
計測
チューニング
負荷テスト
負荷テストシナリオの選定
性能目標値の設定
負荷の生成
計測
チューニング
ロングランテスト
ロングランテストシナリオの選定
負荷の生成
計測
チューニング
スケーラビリティテスト
スケーラビリティテストシナリオの選定
負荷の生成
計測
チューニング