こんにちは、Tochiです。 前回、「ソフトウェアアーキテクチャの基礎 第一章まとめ」というテーマでブログを書いたのですが、 その後、章末ごとにブログを書けず、第一部を読み終えてしまったので一気に簡単にまとめていきたいと思います。
第二章 アーキテクチャ思想
アーキテクトらしく考え、アーキテクチャの観点で物事を見るための側面を４つを紹介している
① アーキテクチャと設計の違い
アーキテクトは、ビジネス要件を分析してアーキテクチャ特性（~~ility）を抽出・定義し、問題領域に適したアーキテクチャパターンやスタイルを選択して システムの構成要素（コンポーネント）を作ることに責任をもつ。 一方、開発者はコンポーネントごとのクラス図やユーザインターフェースとなる画面を作成し、コードを責任・テストすることに責任をもつ。 アーキテクトの考えは往々にして開発者に確実に引き継がれるというわけではないので、メンタリングやコーチングする機会を提供する必要がある。
実体験に置き換えると、私の上司が概念設計とコンポーネント設計をし、それを自分らが実装・開発するといった具合かな。 メンタリングやコーチングはいわゆるコードレビューや1on1を通じて、アーキテクト（上司）と開発者（自分）が双方向のコミューニケーションができるようにする感じですかね。
② 技術的な幅
「アーキテクトは技術の幅、開発者は技術の深さを必要とされる」 知識には、
- わかっていること
- わかっていないとわかっていること
- わかってないとわかっていないこと
の3段階ある。 開発者はこの「わかっていること」の深を深くすることが求められ、アーキテクトは「わかってないとわかっていること」の幅を広げることが重要視される。
それはそうって感じ。 意思決定する上では、知っていることのを幅は広い方がいいし、多少わかってないと思っていてもそれがわかっていれば調べるだけ。 INDEXはたくさんあった方が意思決定はしやすいのだろう。
③ トレードオフを分析する
「アーキテクチャとはGoogleで見つけられないものだ」 技術的なものかどうかに関わらず、あらゆるソリューションのトレードオフを検討し、最善のソリューションを決定することがアーキテクト。 結局アーキテクチャは全てトレードオフ。 何を選択するべきかは企業文化やビジネスドライバーなどあらゆる変数によって時と場合によるので正解も不正解もない。
④ ビジネスドライバーを理解する
システムの成功な必要なビジネスドライバーを理解し、それをアーキテクチャ特性に変換することがアーキテクトに求めらる。 それには、事業ドメイン知識をある程度もち、ステークホルダーと健全かつ協力的な関係を築く必要がある。
第三章 モージュル性
モジュールの定義と計測方法について。 いまいちピンとこなかった章。
凝集度・結合度・コナーセンスの考え方について述べている。 コナーセンスって初めて聞いた。コナーセンスは変更容易性に着目した結合度の測り方で、その定義を簡単に言うと、コードベースにある２つのコンポーネント（関数やクラスやモジュールなど）にコナーセンスがあるというらしい。
かなり概念的な話だったので、「ふーん、そういう計測方法があるんだね」で流した。
第四章 アーキテクチャ特性
ドメインの機能に直接関連しないがソフトウェアが満たさないといけないこと（アークテクチャ特性）を定義し、発見・分析するのがアーキテクトである。 非機能要件という呼び方は、ネガティブな印象を抱くし、品質特性だと設計事後に行う品質評価の印象が強いのでアーキテクチャ特性と呼びたいらしい（筆者曰く）
アーキテクチャ特性は、以下3つの特性を満たす
- ドメインによらない設計に関する考慮事項を明らかにするもの
- アプリケーションが何をすべきかのか明らかにして、システムが成功するために必要な運用と設計の基準を明らかにするのがアーキテクチャ特性。要件を「どう」実装するかと「なぜ」その方法が選ばれたかに関心をもつ。これには明示的な特性と暗黙的な特性がある。（例: 「技術負債にならない」という特性は、要件文書に記されない暗黙的なもの）
- 設計の構造的な側面に影響を与えるもの
- 例えば、「セキュリティ」である。これをアプリケーション内で決済するかサードパーティで実装するかで大きく構造が変わってくる
- アプリケーションの成功に不可欠なもの
アプリケーションはすべてのアーキテクチャ特性を持つこともできない。（セキュリティとパフォーマンスはほぼ確実に影響しあってしまう） そのため、アーキテクトはアーキテクチャ特性を一部しかサポートしない（選択しない）。
また、アーキテクチャ特性が多すぎると、あらゆるビジネス上の問題を解決しようとする汎用的なソリューションになるが、 そうしたアーキテクチャは扱いづらい設計となる、よって最善のアーキテクチャではなく 少なくとも最悪ではないアーキテクチャを狙っていく必要がある。
繰り返しになるが、結局はトレードオフなんだよっていうことを筆者な述べているのかな？？ アーキテクチャのリストが本には記載してあったが、ユーザビリティまで言及していてアーキテクトの奥深さを感じた。。。
第五章 アーキテクチャ特性を明らかにする
アーキテクチャ特性をたくさんサポートするような「汎用アーキテクチャ」はアンチパターン。 サポートするアーキテクチャの数にこだわらずに、設計をシンプルに保つ気持ちが非常に重要。
その中で、サポートするアーキテクチャの優先順位を選んでもらうことは時間の無駄。なぜならステークホルダー全員の同意を得られることはほぼあり得ないから。 （これはめっちゃ共感。営業はパフォーマンスで経営はセキュリティといいだしたら、それこそ困ったことになる）
それよりも最も大事な特性を3つだけ選んでもらうことがいい。
ちなみに、明示的なアーキテクチャ特性もある。 たとえば、大量なアクセスに耐えられる弾力性など。
本章で、アーキテクト・カタに関する話があったがこれはかなり参考になった
いずれにせよ、この章で一番大切なメッセージは 「アーキテクト・開発者・ドメインアナリストが協力して最善の方法を決定すべき」ということ。 象牙の塔のアーキテクトアンチパターンになったら終わりってことですね。。
「アーキテクチャに間違った答えはない。高くつくものがあるだけだ。」 この名言、本当にゾワっとする。
第六章 アーキテクチャ特性の計測と統制
この章はアーキテクチャ特性の計測と統制について焦点を当てている。
アーキテクチャ特性というのは非常にあいまいな言葉で、この言葉について共通の定義を持ちたい。 だから計測によって定義してこうぜって話かな。。？この章はマジでピンとこず
計測としては以下3種類があるとか。
- 運用面の計測
- 構造面の計測
- プロセス面の計測
統制としては、 - 適応度関数を用いて循環依存の発見 - レイヤーの規約違反の発見
ん〜〜ちょっとわかるかも。 テストカバレッジとかESLintとかでimportの禁止したりとかそういうことを言っているのかな〜。。。。
結局のところ、アーキテクチャ特性について各組織で明確な基準を持って、 メンバー間の認識のギャップを埋めようせって感じだと思われる。。
第七章 アーキテクチャ特性のスコープ
アーキテクチャ量子と粒度という新しい考え方。 高度な機能的凝集性と同期的なコナーセンスをもつ、独立してデプロイ可能なアーティファクトということらしい。
運用上の関心ごとについて、スコープを絞ってみることで 早期に課題を発見できる。この時に使うのがアーキテクチャ量子と粒度の話みたいだが、、 結局、アーキテクチャ特性はある範囲の機能を実現するための「アプリケーション群」 + 「依存データストア」に対して定義されるので、 それぞれのドメインのコンテキストごとにアーキテクチャ特性を定義するという、まあ考えてみればそうだよねって感じの主張が並んでいる。
第八章 コンポーネントベース思考
コンポーネントはモジュール化されるアーキテクチャの基本構成である。
アーキテクチャの最上位分割として、 レイヤードアーキテクチャとモジュラーモノリスを比較している。結局これもトレードオフの関係にある。
この章で印象的だったのはコンポーネント発見の方法としてのアクター/ アクションアプローチ。 アプリケーションでアクティビティを実行するアクターと、そのアクターが実行する可能性のあるアクションを特定する
これは結構無意識化でやっていたと思う。 このアプリを使うユーザはなぜ使うのか、どう使いたいのか、実際どう使うのか。 そういったことを考えると自然とコンポーネントは分けようとなる。やっぱり概念設計って大事だなーと思った
まとめ
これで第一部は終わり。 まだ浅い理解でしかないが、それでも得られるものはデカかった気がする！！
