ソフトウェアアーキテクチャの基礎を読んだ

「ソフトウェアアーキテクチャの基礎」を読んだので、印象に残った点などをまとめていきます。

ソフトウェアアーキテクチャとは

本書では冒頭で、「ソフトウェアアーキテクチャとはなにか」について定義しており、ソフトウェアアーキテクチャとは、以下の4つの組み合わせであるとしています。

  • システムの構造
    • そのシステムを実装するアーキテクチャスタイルの種類(マイクロサービスやレイヤードなど)を指します
  • アーキテクチャ特性
    • いわゆる非機能要件と言われるものがこれに該当します。
    • 例としては、セキュリティ、パフォーマンス、可用性、テスト容易性などが挙げられます。
  • アーキテクチャ決定
    • システムをどのように構築すべきかのルールを定めるものです
    • 例えば、レイヤードアーキテクチャ上でビジネス層とサービス層のみがデータベースに直接アクセスできるというアーキテクチャ決定を行うことで、プレゼンテーション層が直接データベースを呼び出すのの制限する、といった決定が該当します。
  • 設計指針
    • アーキテクチャ決定との違いがわかりにくいですが、設計指針は、堅苦しいルールではなくガイドラインであるという点で、アーキテクチャ決定とは異なります。
    • 本書では「開発チームはマイクロサービスアーキテクチャのサービス間の非同期メッセージングを利用してパフォーマンスを向上させるべき」といったものが設計指針の例として挙げられていました。

ソフトウェアアーキテクチャといった言葉は、万人が合意する明確な定義がなく、私自身なんとなくの雰囲気で使用していたように思います。 本書では、ソフトウェアアーキテクチャという言葉の明確な定義を示してくれています。 本書を読む前の自分は、「アーキテクチャ決定」「設計指針」といった概念をうまく整理できていなかったので、勉強になりました。

また、システムの構造を構成するものには、「アーキテクチャスタイル」と「アーキテクチャパターン」があるとしており、本記事では「アーキテクチャスタイルについてもう少し書いていきます。

アーキテクチャスタイルとは

アーキテクチャスタイルとは、システムの構造を構成するもので、本書では以下のように定義されています。

私たちはアーキテクチャスタイルを、フロントエンドやバックエンドのソースコードがどのように編成されているか(モノリス内のレイヤー、あるいは個別にデプロイされるサービスとして)、そしてそのソースコードがどのようにデータストアと相互作用するかについての包括的な構造と定義している。

本書で紹介されているアーキテクチャスタイルはいかになります。

私はWebシステムを開発していることもあり、レイヤードアーキテクチャやイベント駆動アーキテクチャ、マイクロサービスアーキテクチャなどは知っていました。

一方で、本書で紹介されているアーキテクチャの中には私が全く知らなかったものもありました。 特に、マイクロカーネルアーキテクチャは、とても興味深かったです。 マイクロカーネルアーキテクチャは、エディタやIDE、ブラウザなど拡張機能を提供しているソフトウェアに使用されているアーキテクチャです。 私は普段からこのアーキテクチャが採用されているソフトウェアを使っているのにも関わらず、このアーキテクチャの存在を全く知りませんでした。。

ソフトウェアアーキテクチャトレードオフ

本書では、トレードオフという言葉が至ることろに出てきます。

ソフトウェアアーキテクチャトレードオフがすべてだ。ソフトウェアアーキテクトにきれいなスペクトルは存在しない。すべての決定は、多くの相反する要素を考慮しなければならない。アーキテクトが、トレードオフではない何かを見出したと考えているなら、まだトレードオフを特定していないだけの可能性が高い。

 

アーキテクチャではすべてがトレードオフだ。だからこそ、アーキテクチャのあらゆる問いに共通する答えは、「場合による」のだ。この答えにいら立つ人は多いだろう。しかし、残念ながらそれが真実だ。RESTとメッセージングはどちらが良いか。マイクロサービスは正しいアーキテクチャスタイルなのか。こういった問いに対する答えをGoogleで見つけることはできない。それは場合によるからだ。答えは、デプロイ環境やビジネスドライバー、企業文化、予算、期間、開発者のスキルセット、その他ビジネスドライバー、企業文化、予算、期間、開発者のスキルセット、その他多くの要因に依存する。環境や状況、問題点はそれぞれに異なるものだ。だからこそ、アーキテクチャは難しい。

 

プログラマーは利点はわかっているが、トレードオフはわかっていない。アーキテクトはその両方を理解する必要がある。アーキテクチャ的に考えるとは、与えられたソリューションの利点を見るだけでなく、マイナス面も含めてトレードオフを分析するということだ。

すべての状況に適応できる万能なソフトウェアアーキテクチャというものは存在せず、どのソフトウェアアーキテクチャにも必ずメリットとデメリットがあります。 そのため、アーキテクトは、その時々の状況(システムの扱うドメインやチームメンバーのスキル)に応じて、トレードオフを考え、適切なアーキテクチャを見極めなければなりません。

新しいアーキテクチャを勉強すると、ついついそのアーキテクチャのメリットにばかり目が行ってしまい、そのアーキテクチャを採用したくなってしまいます。 しかし、どんなアーキテクチャにもトレードオフはあるので、そのトレードオフをしっかり認識し、本当にそのアーキテクチャが最適なのか考えなければなりません。 ただ、これが非常に難しい。。