Skip to content

toona note

アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築

書評ではありません。 読書メモです。

書籍情報

1章

アーキテクトとは？
ビジネス上の利益を産むために、ソフトウェアの設計をする。
アジリティの確保
コーディング力も必要だがビジネスへの理解も必要

2章

ソフトウエア設計 solidなどの設計原則, 設計パターンについて
アーキテクトよりもよりコードよりの章

ドメインロジックとアプリケーションロジック 違いはわからないでもないけどふわっとしている。
凝集 これも程度についての議論が必要に感じる。 高めていったらクラスにメソッド1個になってしまう。 philosophy of software design でも、コレに似た議論がありました。
GoF 有名だけど自分では読んだことがない。 ... 内容だけ見たところ、言語依存が大きいと感じる。 rust ではいらないパターンがある。 facade と fuctory の違いがわからない。

3章

アーキテクチャ設計 何をしたいか -> トレードオフのある設計からどれを選ぶのか？ -> 論理的な構造モデル 重要な要素。アーキテクチャドライバを特定しよう. たとえばこのシステムには、セキュリティが高度に求められるとか

分散とモノリシック 分散

  • サービスベース
    • 同一DBでトランザクション境界はサービスを跨がない
  • マイクロサービス
    • 各マイクロサービスが独立DBを持ち、サービス間でデータは完全分離 api gateway などで通信する
    • saga パターン ... 複数サービスのトランザクションの整合性実現方法

saga パターン 2相コミット的な補償トランザクションをサービス間で行う 各サービスの調整役を使うオーケストレーションと利用しないコレオグラフィという方式がある. オーケストレーションがおすすめらしい

  • モノリシック
  • モジュラーモノリス

クリーン、パイプライン、マイクロカーネル(プラグイン)などのアーキテクチャスタイル

アーキテクチャを説明する文書 Software Architecture Document (SAD) たとえば 理論 : unified modeling language (UML) などのモデリング言語 開発 : container Az repository みたいな具体的なもの

4+1

  • ロジカルビュー : 論理構造 たとえばレイヤーとか
  • プロセスビュー : user -> system -> DB みたいなトランザクションなど
  • デベロッパービュー : 開発レベル ディレクトリ構造図など
  • フィジカルビュー : Azure VM -> PostgreSQL みたいな物理構成
  • シナリオ

c4 Context : システムの外部との関係 Container : システムの中のコンテナ(アプリケーション、DBなど) Component : コンテナの中のコンポーネント インターフェースを持ちまとまった振る舞いをする Code : コードレベルの構造

4章

開発フローの構築

4.2 ドキュメント

  • 本来はアーキテクトのスコープ外 実業務では入ることが多い ... 確かに、仕事を進める上では重要だし、誰がやるかとなるとアーキテクトを考える人になりそう
  • ユースケースは利用者目線で記述する
    • DBに~があったら ではなくて、記載済みであったら~する　とか
    • クリックなどの interface依存は書かず、登録するなどにする。 ... インターフェースは変えることがあるから？

4.5 開発の準備

  • 規約、手順書 ... これは 4.2の復習的な内容

4.6 ci/cd

CI ... テストなど CD ... デプロイなど. delivery(最終デプロイは手動) と deployment の両方の意味がある

5 品質保証

シフトレフト ... 欠陥の発見工程を前に移す
E2Eテスト、インテグレーションテスト、ユニットテスト E2Eはユーザー観点でのテスト Flaky Test が発生しやすい. 基本的にリグレッションテスト インテグレーションテスト... E2Eとユニットテストの間 ユニットテスト ... クラス単位、コンポーネント単位など議論あり. この辺りは「単体テストの考え方」に詳しい

パフォーマンステスト 大量のデータが必要。分布調整や、Insertをストアドプロシージャとして高速化するなど工夫が必要 負荷テスト スループット パーセンタイル評価が多い

2026 04 13