【読書メモ】ソフトウェアアーキテクチャの基礎

はじめに

この記事はソフトウェアアーキテクチャの基礎を読んでの読書メモです。書いてあることを自分の言葉で説明しようとしてみたり、思ったことを付け加えたりして書いています。

第1章　ソフトウェアアーキテクチャの定義

ソフトウェアアーキテクトに明確な定義がないのはなぜか。それはそもそもソフトウェアアーキテクチャ自体の定義が定まっていないからである。さらに、ソフトウェアアーキテクトの役割がとても広範囲にわたり依然拡大し続けている。また、近年のソフトウェア開発の急速化も相まって、DevOpsやアジャイルによりソフトウェアアーキテクチャが常に変化するものとなったことも要因である。

アーキテクチャとは、文脈によるもの。アーキテクトが下す決定の多くは、彼らが置かれる環境に基づく。例えば、20世紀後半のソフトウェア開発では、共有リソースの効率化が大きな目標の一つだった。OS、サーバーどれをとっても当時インフラは高価なものだった。この時代にそれぞれのサービスでDBをもって独自のマシンで動かすアーキテクチャを考えても到底実現できるものではなかった。しかし、現代ではそのアーキテクチャはマイクロサービスと呼ばれ、インフラの汎用化やDevOpsの台頭によって当たり前のものになった。このようにアーキテクチャは文脈によって成り立つのである。

最近はDockerがメジャーになりつつあるのもあって、クラウドインフラだけでなくDockerも話になりそう。人の入れ替わり、マシンの入れ替わりが激しくて環境構築のし直しが発生しやすいからDocker使っておこう、といったところだろうか。

ソフトウェアアーキテクチャの定義

ソフトウェアアーキテクチャの基礎では、ソフトウェアアーキテクチャの定義以下の4つとしている。

1. システム構造
2. アーキテクチャ特性
3. アーキテクチャ決定
4. 設計指針

システム構造

システムのアーキテクチャスタイルを指す。例えばマイクロサービス、レイヤード、マイクロカーネル。

アーキテクチャ特性

いわゆる「イリティ（-ility）」、非機能要件。

アーキテクチャ決定

システムを構築する際のルール。例えば、レイヤードアーキテクチャが採用されたとして、アーキテクトはビジネス層とサービス層のみが永続化層にアクセスできる、というルールを決定すること。なんらかの条件や制約によって、ルールが破られることもある（特例）。特例措置を取る場合は、プロセスを設け正当性やトレードオフを考慮し判断する。開発チームの指針となる。

設計指針

システム構築する際のガイドライン。例えば、マイクロサービスのサービス間のやり取りでは非同期メッセージングを利用してパフォーマンスを向上させることが示されているとする。これは、設計指針として、非同期メッセージングを利用するという望ましいアプローチが提示されているのである。

アーキテクチャ決定はルール、設計指針はガイドラインということだが、ルールとガイドラインの違いは何？と思い調べてみた。
ルールは日本語で規則、規則は決められたことに基づいて手続き、操作が行われること。ガイドラインは指針、向かうべき方針を示したもの。アーキテクチャ（システム構造やアーキテクチャ特性）が決まってくれば、そのアーキテクチャに従ってアーキテクチャ決定や設計指針が作れるというイメージを持った。

ソフトウェアアーキテクト

以下の8つが期待される。

1. アーキテクチャ決定を下す
2. アーキテクチャを継続的に分析する
3. 最新のトレンドを把握し続ける
4. 決定の遵守を徹底する
5. 多様なものに触れ、経験している
6. 事業ドメインの知識を持っている
7. 対人スキルを持っている
8. 政治を理解し、舵取りする

第2章 アーキテクチャ思考

アーキテクトらしく考えることには、4つの側面がある。

1. アーキテクチャと設計の違いを理解し、アーキテクチャを機能させるために開発チームとどう協働するか
2. 技術的深さをもちつつ、他の人には見えない解決策や可能性を見出せる広範な技術知識をもつ
3. 解決策と技術の間にあるトレードオフを理解して、分析し調整できる
4. ビジネスドライバーの重要性を理解し、どのようにアーキテクチャに反映されるか理解している

アーキテクチャと設計

アーキテクトはビジネス要件を分析して、アーキテクチャ特性を抽出したり、アーキテクチャのパターンを選択したり、コンポーネント構造を設計したりする。これらの成果物が開発者に引き継がれ、実装、テストを進める。
アーキテクチャを機能させるには、アーキテクトと開発者の間で双方向のコミュニケーションが行われ両者で断絶のないことが望ましい。今日では両者がコラボレーションして、プロジェクトのイテレーションやフェーズと共にアーキテクチャも変化していくことがよい。本書内では、アーキテクチャと設計に明確な境界はなく、どうちらもプロジェクト内の構成要素としてあり常に同期されているべきとなっている。

第3章　モジュール性

この章ではまず以下のMyers(1978)の言葉を引用し、「モジュール」の定義は曖昧であると指摘している。
（ソフトウェアアーキテクチャに関する）言説の95%は、「モジュール性」の利点を賞賛するために費やされている。しかし、それを実現する方法については、多少はあるにしても、ほとんど語られていない。
そこで本書独自の定義を打ち出している。

定義

関連するコードを理論的にグループ化するもの。物理的な分離は意味せず、論理的な分離を指している。例えばJavaのパッケージがある。

Javaではjarをモジュールと言ったりするが、jarはこの定義に当てはまらない理解であっているのだろうか・・・？

第4章　アーキテクチャ特性

アーキテクチャ特性とは、以下3つの基準を満たすもの。

• ドメインによらない、設計に関する考慮事項を明らかにするもの
• 設計の構造的側面に影響するもの
• アプリケーションの成功に不可欠、または重要なもの

アーキテクチャ特性は暗黙的なもの、明示的なものに細分化できる（この内容については5章）。アーキテクトは、分析段階でこれらのアーキテクチャ特性を明らかにしなければならない。

少なくとも最悪でないアーキテクチャ

アーキテクチャ特性をすべて取り入れることは現実的ではなく、選択による関心事のトレードオフである。あらゆるアーキテクチャ特性を実現しようとすると、複雑怪奇なものになる。少なくとも最悪でないアーキテクチャを目指そう。
また、示唆として最初から完璧なものをつくるのではなく、そのときどきに合わせて変更可能にした変更容易性の高いものにすれば、軌道修正もしやすい。

変更しやすいアーキテクチャが最強なのでは、と思ってしまうがどうなんだろう。

長く使うものについては変更しやすいアーキテクチャでも良いかもしれないが、PoCだったりスタートアップのプロダクトだったら変更しやすくなるよう時間をかけるくらいならさっさと作りたいという考え方になりそう。

第5章　アーキテクチャ特性を明らかにする

アーキテクチャ特性を明らかにすることは、アーキテクチャの作成や判断への最初のステップ。アーキテクチャ特性を明らかにするには、ドメインの問題を理解するだけでなく、ステイクホルダーと協力して重要なことを見極める必要もある。アーキテクチャ特性を明らかにしていく観点として、ドメインの関心事、要件、暗黙的なドメイン知識の少なくとも3つがある。

ドメインの関心事

主要ドメインのゴールや状況を理解することで、アーキテクトはドメインの関心事をアーキテクチャ特性に変換できる。
アーキテクチャ特性を定義する際には、アーキテクチャ特性の数をできるだけ絞ること。すべて取り込もうとすることはアンチパターン。また、定義していく際には優先順位をつけたくなるが、これは無駄やステイクホルダーとの不要な摩擦や意見の相違を生み出すことにつながる。より良い方法は、主なステイクホルダーに必要とされるアーキテクチャ特性の中から3つを選んでもらうこと。合意を得やすく、議論を促してトレードオフ分析にも役立つ。
ほとんどのアーキテクチャ特性は、主要なステイクホルダーとともに何がドメインにとって重要か決めていくことで明らかになっていく。しかし、アーキテクトとドメインのステイクホルダーとの対話で情報が落ちてしまう問題が発生する。そのため、以下の表のように、いくつかのドメインの関心事はアーキテクチャ特性と対応関係が一般化されている。

そして重要なのは、市場投入までの時間を満たすために、アジリティだけを満たせばよいのではなく、アジリティとテスト容易性とデプロイ容易性のいずれも満たさねばならない。すばやく開発できても、テストで膨大な時間がかかっては意味がなく、デプロイでも時間がかってしまっては市場投入までの時間は長くなってしまう。

要件

アーキテクチャ特性の中には、ドキュメントで明示されるものもある。例えばユーザー数やスケールに関する事項などで、これらはドメインやドメインへの関心事として扱われる。
大学生の履修登録をするアプリケーションを設計していたとして、学生が1000人いて、登録に10時間かかるとする。このとき、アーキテクトは学生が均等に分散することを想定するのか、履修登録期間の終盤で学生の利用が集中することを想定するか、学生の振る舞いを考慮できるかが鍵になる。こういったドメイン知識はあまり明文化されず、アーキテクトがそのような知識をもつ場合有益である。