勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

「ソフトウェアアーキテクチャの基礎」を読む Part.2

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第62回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら

さて、今回は前回につづき「ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ」である。けっこう分厚いので3回(×2週間)に分けて読んでいる。今回は「第II部 アーキテクチャスタイル」を読んでいく。

アーキテクチャスタイル

本書における「アーキテクチャスタイル」の定義は以下のようだ。

これは一般的な定義と同一のよう。

ただ、パタンランゲージの話と(自分は)混同しがち。気をつけよう。

ほとんどのアーキテクチャスタイルは、繰り返し現れる特定のパターンに気がついたアーキテクトたちによって、後から命名される。次に来る大きなムーブメントを決めるような、秘密のアーキテクトグループが存在しているわけではない。むしろ、アーキテクチャスタイルの流行は、ソフトウェア開発のエコシステムが変化していく中で、多くのアーキテクトが共通の意思決定をしていることを表している。人々に模倣されるようなアーキテクチャスタイルは、ソフトウェア開発のエコシステムの変化に対処し、そこから利益を得るための共通で最善の方法から生まれてくるのだ。

本書で紹介されるアーキテクチャスタイル

「第II部 アーキテクチャスタイル」では以下のようなアーキテクチャスタイルが紹介される。巨大な泥団子から話が始まるのがすき。

「スペースベースアーキテクチャ」はほとんど遭遇したことのないやつ。あと「サービスベースアーキテクチャ」はこういった名前付けを知らなかった。
それぞれのスタイルに対しての評価が付されているのは興味深い。

第II部で興味深かった記述

9章 基礎

10章 レイヤードアーキテクチャ

16章 オーケストレーション駆動サービス指向アーキテクチャ

  • いわゆるSOAのことだが、メタクソにいわれていておもしろい

もしかすると、このアプローチが魅力的なものに聞こえたかもしれない。しかし、実際には、こうしたアプローチのほとんどが失敗に終わった。トランザクションの動作をオーケストレーションツールにオフロードすることは良いことのように聞こえるが、トランザクションの粒度を適切なレベルで見つけ出すのは、ずっと難しいものだった

このアーキテクチャで最も致命的だったのは、技術による分割を重視したアーキテクチャ構築が非現実的であると実感したことだった。

  • まあ、言いたいことはわかる。実際に難しかった。

次回は「第III部 テクニックとソフトスキル」である。アーキテクチャではなく、アーキテクトという職業について語られていると思われるので楽しみだ。