技術書読書ログ「ソフトウェアアーキテクチャの基礎」
概要
オライリーの"ソフトウェアアーキテクチャの基礎"を読みました。
アーキテクチャは何かを選択する際は全てにトレードオフがついてまわる。なので、その決定時にはHowよりWhyを重視することが大事。
またビジネス、テクノロジー、人・組織は刻一刻と変化していく。そしてアーキテクチャは状況によって向き・不向きがあるもの。なので、最善ではなく最悪を避けることを意識して、その代わりにイテレーティブに進化できるようにする。
これらのためには、幅広い知識が必要。技術的なものだけではなく、対人関係のスキルも磨く必要があり、ビジネス側とも開発者とも一緒に協業して作り上げていく。
個人的な学び・気付きポイント3点
アーキテクチャスタイル
モノリスにはレイヤードアーキテクチャ以外にも、パイプラインアーキテクチャとマイクロカーネルアーキテクチャがある。
パイプラインアーキテクチャはUNIXのシェルや関数型プログラミングの考え方をアーキテクチャに持ってきたもの。フィルターのおかげでレイヤードよりもデプロイとテストが容易。フィルターは自己完結型で、他のフィルターからは独立している、ステートレスな、1つのタスクのみを行うコンポーネント。
マイクロカーネルアーキテクチャは別名プラグインコンポーネントと呼ばれるもの。最小限のコアシステムとシステムをカスタマイズ・拡張できるプラグイン群の2種類のコンポーネントからなる。製品パッケージ向けのアーキテクチャ。
マイクロサービスのハイブリッドであり、他の分散アーキテクチャよりもシンプルでコストが低く、実用的なサービスベースアーキテクチャというスタイルもある。UI→ドメインサービス群→DBの3層構造がベース。DDDとも相性が良い。DBの変更に強くするためDBをドメインサービス毎に論理的に分割する方法も取れる。
アーキテクチャ適応度関数
実際のシステムが、目的のアーキテクチャの特性と整合性が取れているか、客観的に評価・統制するための何らかの仕組みをアーキテクチャ適応度関数という。
検証方法は多種多様。既存のツールに新しい視点を加えて自作することもする。
例えば、開発者にモジュール性を守ってもらいたい場合には、以下のような仕組みが有効。
- 循環依存を検出するために、JDependをつかってパッケージ間の依存関係をチェックする
- 主系列からの距離をJDependを使って計測して、一定の範囲内に無いものを検出する
- レイヤードアーキテクチャで、レイヤー間の依存関係が守られているか、ArchUnitを使ってチェックする
パーソナルレーダー
開発者たちが技術の進歩に乗り遅れないようにするための、既存技術と進行技術のリスクとリターンを評価する、常に更新され続ける生きたドキュメント。
ThoughtWorksのBuild Your Own Radar のツールを使えば、Googleスプレッドシートに入力したものを可視化してくれる。
感想
技術的な知識だけでも幅広く、最新もキャッチアップして、深さも維持。それに加えて様々な対人関係のスキルも必要。
アーキテクチャ作りはハードだなと思うけど、逆に言えばアーキテクチャに真剣に向き合うことで、これらを身につけられるなとも思えたので、常に学び、常に練習し、そして実践していきたい！
まずはパーソナルレーダー作ってみたり、モジュール性の適応度関数を実務で取り入れてみたり、Architectural Kataをやってみます！
Discussion