ソフトウェアアーキテクチャとソフトウェアデザイン
SHARES
ソフトウェアアーキテクチャとソフトウェアデザイン。
人によっては単なる言語表現の違いで、同じ意味として捉えられていたりもするが、自分は明確に別の概念や考え (類似点や接合点は存在する) 、次元として捉えてている (概念に線を引いている) 。
本を読んでいたり、人と話をしている時、その話題はアーキテクチャのことに言及しているのか、はたまたデザインについて言及しているのかは常に意識して頭を切り替えている。
もちろん、両方の場合もある。
ソフトウェアの構造に関する概念であるということは同じだが、これらは扱う抽象度が異なる。
ソフトウェアアーキテクチャは抽象度が高い。
アーキテクチャ特性、アーキテクチャスタイル、コンポーネント構造といった概念で構成される。
抽象度が高いので、及ぼす影響範囲も広いが、詳細な実装表現に対する言及はない。
ソフトウェアデザインは抽象度が低い。
クラス設計、インターフェイス、アルゴリズムといった概念で構成される。
抽象度が低いので、及ぼす影響範囲は狭いが、詳細な実装表現に対して言及する。
2つに明確な接合点は存在しないが、概念が繋がる箇所は多くある。
ソフトウェアアーキテクチャの意思決定がソフトウェアデザインの表現に影響を及ぼすし、ソフトウェアデザインでの意思決定がソフトウェアアーキテクチャの特性の獲得に影響を及ぼしたりする。
それぞれは切り離して概念定義がなされており、研究分野としても存在しているが、現場レベルの実践では切り離されることはなく、まとめて取り扱われることが多い。そうしなければ現場では課題解決が進まないのと、真に良いソフトウェア、ソフトウェアの成功を作ることができないからだ。
〇〇アーキテクチャというアプリケーション実装HowToやアーキテクチャパターンの話題をまとめて「アーキテクチャ」という言葉で括られて語られているのはそのせい。
厳密には「アーキテクチャパターンによる、ソフトウェアデザイン手法とプラクティス」という表現が正しい。この話題の厳密さを追い求めることに意味があるのかというと現場的にはほとんどないので、同じ概念として扱われる。これが誤解を生む根源だと思っている。
現場は論理的な棲み分けの明確さよりも、生み出せる価値を一番に考える。
コンピュータサイエンスを学んだ人からするとこの線引きが明確になされているので、混乱しない (することが少ない) 。一方そうでない人、開発現場を経験した後に概念理解に踏み込む人は混乱する人が多い印象を受ける。
それは先の通り、現場レベルでは切り離されることはなく、まとめて取り扱われているからだ。
現場では切り分けて話す必要がなかったり、厳密に棲み分けて話す必要もないため、曖昧に話が進むことが多く、それを最初に見てしまうと、どこに考えの線引きが存在するのか認識するのが難しいし、理解に至るきっかけも掴みづらい。なんなら同じ概念として考えている人もいる。(考えを持つこと自体は間違いではない)
少なくとも自分が経験した現場ではだいたいがそうだった。
自分が明確に別物として扱った方が良いと考える理由は、分けて考えたほうが建設的な議論ができるし、分けて話ができる人の方が正しい判断ができるから。正しい議論は正しい成果を生む。分けて考えるシーンと統合して考えるシーンの使い分けができるのが一番の理想。
また、自身の困りごとの対象が抽象的な意思決定に関することなのか、それとも命名や結合といった詳細に関することなのか、それぞれを切り分けて考え、最も理解のある人に相談した方が、適切なフィードバック、適切な対話ができるように思う。
詳細な実装表現に対して相談しているのに対して、抽象的なフィードバックをもらったところで、なんとくの理解は及ぶものの、それを正しく成果に反映できるかは怪しい。
ソフトウェアアーキテクチャとソフトウェアデザインは別の概念だという認識を持った方が良い。