「ソフトウェアアーキテクチャの基礎」本はアーキテクトが読むべき本だった

ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ 著者 : Mark Richards オライリージャパン 発売日 : 2022-03-08 ブクログでレビューを見る»

「ソフトウェアアーキテクチャの基礎」は良い本と思う。
アーキテクトが読むべき本だったと思う。
ラフなメモ。

【1】ソフトウェアアーキテクチャの定義とは何か？
以前の定義は、ソフトウェアアーキテクチャとは後から変更することが難しいモノだった。
しかし、今は、マイクロサービスの出現により、変化しやすい設計を指すようになって、ガラリと変わった。

【2】アーキテクチャの重要な要素は、トレードオフの決定だ。
品質、コスト、スケジュール、スコープのバランスから、一番最良のものを選ぶ。
それぞれの要素を最大限にするのではなく、トータルでバランスが取れているものを選ぶ。

【3】アーキテクトに期待されている役割。

アーキテクチャ決定を下す。
アーキテクチャを継続的に分析する。
アーキテクチャの最新のトレンドを把握している。
アーキテクチャ決定の順序を徹底している。
様々な技術に精通している。
事業ドメインに詳しい。
対人スキルや政治力を持つ。

【4】ソフトウェアアーキテクチャを語る上で、XPの偉大さがある。

XPでは、プロセスよりも経験的に知られていたプラクティスを重視した。
たとえば、テストが多いほど品質が良くなる経験から、テスト駆動を生み出した。
継続的インテグレーション、コードの共同所有、継続的デプロイなど。

【5】ソフトウェアアーキテクチャの法則は2つ。

1つは、トレードオフが全て。
トレードオフが見つからないならば、分析が不十分な事実を知るべきだ。

2つ目は、HowよりもWhyが大事。

【6】モジュール性とは何なのか？

モジュール分割するアーキテクチャのテクニックの利点は分かる。
しかし、モジュールの実現方法はあまり知られていない、とメイヤーは言った。
この話は、コンポーネント志向につながる。

Javaならば、当初のJDKはパッケージで分割した。
しかし、それだけでは扱いづらいので、Jarというコンポーネントが導入された。
しかし、Jar同士でパッケージ名が衝突する場合があるから、module systemがJava9から導入された。
つまり、Javaもモジュール性の実装方法に苦労している。

【7】本の途中のコラムがとても参考になる。

【7-1】スウェーデンで軍艦ヴァーサ号を製造したが、初めて処女航海に出ようとした時に、すぐに港で沈没した話。

失敗の原因は、アーキテクチャ特性を全部盛り込みすぎて、軍艦が重すぎてしまい、バランスが取れなくなり沈没した。
数多くの利害関係者の要求を最新鋭の軍艦に盛り込んだために、軍艦として実現できなかった。

今のソフトウェアアーキテクチャの話も同じ。
ユーザのたくさんの要望を盛り込みすぎると、結局使い勝手の悪いシステムになってしまうし、それ以前にスケジュールが伸びすぎて永遠にリリースされないシステムになるリスクすらある。

【7-2】ドメイン駆動設計の意義は、境界づけられたコンテキストという概念により、アーキテクチャ設計手法が大きく変わった点にある。

ドメイン駆動設計の出現以前は、組織内の共通エンティティは再利用を重視していた。
しかし、再利用を重視しすぎて、ビルドが困難になり、チーム間の調整が難しくなり、ソフトウェアの複雑さが増大し、多くの問題を引き起こした。
たぶん、ソフトウェアプロダクトラインの話も同じ。

ドメイン駆動設計の出現後、境界づけられたコンテキストの考え方により、各エンティティは局所化されたコンテキストの中で最もよく機能すればいい。
つまり、組織全体の共通エンティティは不要であって、問題領域ごとにエンティティを自由に作り、その中で最適化されたエンティティを作ればいい。
問題領域のドメインの境界上で調整すればいい。
つまり、この考え方がマイクロサービスにつながるわけだ。
マイクロサービスの実装言語はGo言語が主流である。

各ドメイン内のシステムはRailsだったりPythonだったりPHPでもよく、複数のプログラミング言語で作られたシステムとGo言語によるマイクロサービスがAWSのようなクラウド上で動くアーキテクチャが多いわけだ。

【8】コンポーネント設計では、分割の観点は何か？

コンポーネント設計とは、アーキテクチャの分割であるという考え方。
レイヤーアーキテクチャがよく使われる。
たとえば、Javaの依存性注入（DI）、DLLやJarなどのコンポーネント。

この考え方を進めると、開発スタイルはコンウェイの法則に縛られることになり、複雑な組織構造が反映された複雑なアーキテクチャになってしまう。
だから、逆コンウェイ戦略という考え方が出てきた。

一方、コンポーネント設計とは、ドメインによる分割であるという考え方。
これはドメイン駆動設計であり、マイクロサービスアーキテクチャにつながる。

ドメインごとに開発チームを作ることにより、コンウェイの法則のリスクを避けられる。
逆コンウェイ戦略をそのまま実現しやすい。

【9】アーキテクチャスタイルとは、アーキテクチャのパターン集。

モノリシックアーキテクチャと分散アーキテクチャに分かれる。

モノリシックアーキテクチャ：

レイヤーアーキテクチャ　→TCP/IPとか。
パイプラインアーキテクチャ　→Unixとか。
マイクロカーネルアーキテクチャ　→コアシステム＋プラグインの構造。Eclipse、Jira、Jenkinsとか。

分散アーキテクチャ：

サービスベースアーキテクチャ　→フロントエンド＋バックエンド
イベント駆動アーキテクチャ　→デスクトップアプリ。非同期システム。
スペースベースアーキテクチャ　→ロードバランサー。インフラの仮想化。クラウド。
オーケストレーション駆動サービス指向アーキテクチャ　→よく分からない。使われない。
マイクロサービスアーキテクチャ　→ドメイン駆動設計とか。

分散アーキテクチャが今の流行だが、8個の誤信がある。
ネットワークは信頼できる。
レイテンシーがゼロ。
帯域幅は無限。
ネットワークは安全。
トポロジーは決して変化しない。
管理者は1人だけ。
転送コストはゼロ。
ネットワークは均一。

他にも、分散ロギング、分散トランザクションなどもある。

これらの観点をトレードオフとして考えるべき。