2015年のOSCONでは、アーキテクチャとは何か、そしてなぜそれが重要なのかについて短い講演（14分）を行いました。
ソフトウェアアーキテクチャガイド
ソフトウェア業界で「アーキテクチャ」について議論する際、それはソフトウェアシステムの内部設計における最も重要な側面に関する、曖昧に定義された概念を指します。優れたアーキテクチャは重要です。そうでなければ、将来、新しい機能を追加することが遅く、高価になります。
ソフトウェア業界の多くの人々と同様に、私も長年「アーキテクチャ」という用語に警戒してきました。それはしばしばプログラミングからの分離と不健全なほどの尊大さを示唆するからです。しかし、私は、優れたアーキテクチャはそれ自身の進化をサポートし、プログラミングと深く関連していることを強調することで、懸念を解消しています。私のキャリアの大部分は、優れたアーキテクチャがどのようなものか、チームがどのようにそれを作成できるか、そして開発組織においてアーキテクチャ思考をどのように育成するのが最善かという問題を中心に展開してきました。このページでは、ソフトウェアアーキテクチャに関する私の見解を概説し、このサイトのアーキテクチャに関するより多くの資料へのリンクを示します。
martinfowler.comのソフトウェアアーキテクチャに関する資料へのガイド。
アーキテクチャとは何か？
ソフトウェアの世界では、アーキテクチャの定義について長年議論されてきました。ある人々にとって、それはシステムの基本的な構成、または最上位レベルのコンポーネントがどのように接続されているかのようなものです。このことについての私の考え方は、Ralph Johnson氏とのメールのやり取りによって形成されました。彼はこの表現に疑問を呈し、何が基本的なものか、または上位レベルのものかを客観的に定義する方法がなく、アーキテクチャのより良い見方は、熟練した開発者がシステム設計について共有している理解であると主張しました。
QConで講演するRalph Johnson氏
アーキテクチャの定義のもう一つの一般的なスタイルは、「プロジェクトの初期段階で決定する必要がある設計上の決定」です。しかし、Ralph氏はこれについても不満を述べ、「それはプロジェクトの初期段階で正しくしたいと願う決定のようなものだ」と言いました。
彼の結論は、「アーキテクチャは重要なものについてです。それが何であれ」でした。一見すると、それは陳腐に聞こえますが、私はそれが多くの豊かさを含んでいることに気づきました。つまり、ソフトウェアについてアーキテクチャ的に考えることの核心は、何が重要であるか（つまり、何がアーキテクチャであるか）を決定し、それらのアーキテクチャ要素を良好な状態に保つことにエネルギーを注ぐことです。開発者がアーキテクトになるためには、どの要素が重要であるかを認識し、制御されなければ深刻な問題を引き起こす可能性のある要素を認識する必要があります。
Ralph氏のメールは、IEEE Software誌への私のコラムの中核を成し、ソフトウェアアーキテクチャの意味とアーキテクトの役割について議論しました。
なぜアーキテクチャは重要なのか？
アーキテクチャは、ソフトウェア製品の顧客やユーザーにとっては難しい問題です。それは彼らがすぐに認識するものではないからです。しかし、貧弱なアーキテクチャは、クラフト（開発者がソフトウェアを理解する能力を妨げるソフトウェアの要素）の増加の主要な原因となります。多くのクラフトを含むソフトウェアは修正がはるかに困難になり、機能がより遅く、より多くの欠陥を伴って到着することにつながります。
この状況は、私たちの通常の経験とは逆です。「高品質」なものは、より高価なものとして認識されています。ユーザーエクスペリエンスなど、ソフトウェアのいくつかの側面では、これは真実です。しかし、アーキテクチャやその他の内部品質の側面に関しては、この関係は逆転します。高い内部品質は、邪魔になるクラフトが少ないため、新しい機能のより迅速なデリバリーにつながります。
短期的にクラフトの蓄積が影響を与える前に、品質を犠牲にして迅速なデリバリーを行うことは確かにできますが、人々はクラフトが全体的なデリバリーの遅延につながる速度を過小評価しています。これは客観的に測定できるものではありませんが、経験豊富な開発者は、内部品質への配慮は数ヶ月ではなく数週間で報われると考えています。
アプリケーションアーキテクチャ
ソフトウェア開発における重要な決定は、私たちが考えているコンテキストの規模によって異なります。一般的な規模はアプリケーションの規模であるため、「アプリケーションアーキテクチャ」と呼ばれます。
アプリケーションアーキテクチャを定義する際の最初の問題は、アプリケーションの明確な定義がないことです。私の見解では、アプリケーションは社会的構築物です。
- 開発者によって単一の単位として認識されているコードの集合
- ビジネス顧客が単一の単位として認識している機能のグループ
- 資金提供者が単一の予算として認識している取り組み
このような緩やかな定義は、開発チームの人数から、数人から数百人まで、アプリケーションの潜在的なサイズを多く生み出します。（サイズを関係者の人数として見ていることに気づかれるでしょう。これは、そのようなものを測定する上で最も有用な方法だと感じているからです。）これとエンタープライズアーキテクチャの主な違いは、社会的構築物に関して統一された目的の度合いが非常に高いことです。
アプリケーション境界
ソフトウェア開発における未解決の問題の1つは、ソフトウェアの境界を決定することです。（ブラウザはオペレーティングシステムの一部ですか、そうでないですか？）サービス指向アーキテクチャの多くの支持者は、アプリケーションは消滅しつつあり、したがって将来のエンタープライズソフトウェア開発はサービスの組み合わせに関するものになると考えています。
アプリケーション境界を明確に定義するのが難しいのと同じ理由で、アプリケーションは消滅しないと私は考えています。本質的に、アプリケーションは社会的構築物です。
マイクロサービスガイド
マイクロサービスアーキテクチャパターンとは、単一のアプリケーションを、それぞれ独自のプロセスで実行され、軽量なメカニズム（多くの場合、HTTPリソースAPI）で通信する小規模なサービスのスイートとして開発するアプローチです。これらのサービスは、ビジネス機能を中心に構築され、完全に自動化されたデプロイメント機械によって独立してデプロイ可能です。これらのサービスの中央集権的な管理は最小限であり、異なるプログラミング言語で記述され、異なるデータストレージテクノロジーを使用している可能性があります。その利点により、ここ数年非常に流行していますが、分散の増加、一貫性の弱体化、運用管理の成熟度を必要とするというコストが伴います。
サーバーレスアーキテクチャ
サーバーレスアーキテクチャとは、サードパーティの「Backend as a Service（BaaS）」サービスを組み込んだり、「Functions as a Service（FaaS）」プラットフォーム上で管理された一時的なコンテナで実行されるカスタムコードを含んだりするアプリケーション設計です。これらのアイデアと、シングルページアプリケーションなどの関連するアイデアを使用することで、このようなアーキテクチャは、従来の常時稼働サーバーコンポーネントの必要性を大幅に削減します。サーバーレスアーキテクチャは、運用コスト、複雑さ、エンジニアリングのリードタイムの大幅な削減という利点を得られる可能性がありますが、ベンダーへの依存の増加と比較的に未成熟なサポートサービスというコストが伴います。
マイクロフロントエンド
優れたフロントエンド開発は困難です。多くのチームが同時に大規模で複雑な製品に取り組めるようにフロントエンド開発をスケールアップすることは、さらに困難です。この記事では、フロントエンドモノリスをより小さく、より管理しやすい多くのピースに分割する最近の傾向と、このアーキテクチャがフロントエンドコードに取り組んでいるチームの有効性と効率を向上させる方法について説明します。さまざまな利点とコストについて説明するだけでなく、利用可能な実装オプションの一部についても説明し、この手法を示す完全なサンプルアプリケーションに深く掘り下げます。
GUIアーキテクチャ
2000年代半ば、私は書籍になり得るいくつかの執筆プロジェクトを進めていましたが、まだ実現していません。1つはユーザーインターフェースのアーキテクチャに関するものでした。この作業の一環として、フォームとコントロールのデフォルトのアプローチとModel-View-Controller（MVC）パターンを比較して、GUIアーキテクチャがどのように進化したかの説明を起草しました。MVCは、ソフトウェアの世界で最も誤解されているパターンの1つであり、十分に文書化されていなかったため当然のことです。そのため、ここの記述では、MVCの真の意味と、Model-View-Presenterなどの他の形式を通じてどのように進化したかをより明確に示そうとしています。
プレゼンテーション・ドメイン・データのレイヤリング
情報が豊富なプログラムをモジュール化するための最も一般的な方法の1つは、プレゼンテーション（UI）、ドメインロジック（別名ビジネスロジック）、データアクセスという3つの広範なレイヤーに分離することです。そのため、Webアプリケーションは、HTTPリクエストの処理とHTMLのレンダリングを認識するWebレイヤー、検証と計算を含むビジネスロジックレイヤー、データベースまたはリモートサービスで永続的なデータを管理する方法を整理するデータアクセスレイヤーに分割されることがよくあります。
分散システムのパターンカタログ
分散システムは、プログラミングにおいて特有の課題をもたらします。多くの場合、データの複数コピーが必要となり、それらを同期させる必要があります。しかし、処理ノードが確実に動作するとは限らず、ネットワーク遅延は容易に不整合につながる可能性があります。それにもかかわらず、多くの組織は、データストレージ、メッセージング、システム管理、およびコンピューティング能力を処理する様々なコアとなる分散ソフトウェアに依存しています。これらのシステムは共通の問題に直面しており、同様のソリューションでそれらを解決しています。2020年、Unmesh Joshiはこれらのソリューションをパターンとして収集し始め、開発に合わせてこのサイトで公開しました。2023年には、これらのパターンが「Patterns of Distributed Systems」という書籍として出版されました。このページでは、各パターンの短い概要へのリンクと、oreilly.comのオンライン電子書籍版の関連する章へのディープリンクを提供しています。
フィーチャートグル（別名フィーチャーフラグ）
フィーチャートグル（フィーチャーフラグとも呼ばれる）は強力なテクニックであり、コードを変更せずにシステムの動作を変更できます。これらは様々な使用カテゴリに分類され、実装と管理を行う際には、その分類を考慮することが重要です。トグルは複雑さを導入します。スマートなトグル実装プラクティスと適切なツールを使用してトグル構成を管理することで、その複雑さを抑制できますが、システム内のトグルの数を制限することも目指すべきです。
確立されたUIパターンを用いたReactアプリケーションのモジュール化
確立されたUIパターンは、UIデザインにおける複雑な問題解決における有効性が実証されているにもかかわらず、フロントエンド開発の世界ではしばしば十分に活用されていません。この記事では、確立されたUI構築パターンをReactの世界に適用する方法を、リファクタリングジャーニーコード例を用いてその利点を示しながら探ります。重点は、階層化アーキテクチャがどのようにReactアプリケーションの整理に役立ち、応答性の向上と将来の変更に対応できるようになるかです。
エンタープライズアーキテクチャ
アプリケーションアーキテクチャはある種の概念的なアプリケーション境界内のアーキテクチャに焦点を当てている一方で、エンタープライズアーキテクチャは、大規模な企業全体にわたるアーキテクチャを検討します。そのような組織は通常、そのソフトウェアを何らかのまとまったグループにまとめるには大きすぎます。そのため、互いに独立して開発された多くのコードベースを持つチーム間での調整が必要となり、資金調達とユーザーは互いに独立して運営されています。
エンタープライズアーキテクチャの多くは、中央調整の費用に見合う価値のあるものと、その調整がどのような形態をとるべきかを理解することにあります。極端な例としては、企業内のすべてのソフトウェアシステムのアーキテクチャ上のすべての決定を承認しなければならない中央アーキテクチャグループがあります。このようなグループは意思決定を遅らせ、非常に幅広いシステムポートフォリオ全体の問題を真に理解することができず、結果として悪い意思決定につながります。しかし、もう一方の極端な例は、全く調整がないことで、チームが努力を重複させ、異なるシステムが相互運用できなくなり、チーム間のスキル開発とクロスラーニングが不足することです。
アジャイルな考え方を持つほとんどの人と同様に、私は非中央集権化の側に傾いており、窒息させるような管理よりも混沌の岩礁に近づくことを好みます。しかし、チャネルのその側にいるということは、依然として岩礁を避けなければならないことを意味し、実際の費用を最小限に抑えながら、ローカルな意思決定を最大化する必要があります。
エンタープライズアーキテクトがチームに参加する
エンタープライズアーキテクチャグループは、日常の開発から分離されることがよくあります。これにより、開発作業に関する彼らの知識が時代遅れになり、開発チームが会社全体の幅広い視点を取らなくなる可能性があります。これを頻繁に目撃してきた私の同僚（Thoughtworks CTO）のRebeccaは、エンタープライズアーキテクトは開発チームに参加することで、はるかに効果的になることができると主張しています。
統合されたビジネスとテクノロジー戦略の策定
テクノロジーを効果的に活用するには、テクノロジーに関する考え方を基礎となるビジネスプランと整合させる必要があります。テクノロジー戦略は、ビジネスとテクノロジーを適切に統合することで、この整合性を推進できます。私たちは、戦略的イニシアチブの共通の側面を認識することに基づいて、この戦略的思考を支援するための概念的フレームワークを開発し、11の普及している戦略的方向性を特定しました。各方向について、それらが提起する主要なビジネス上の課題と、テクノロジーへの影響を探るために必要な調査の概要を示します。このフレームワークは、より効果的なテクノロジー戦略につながるだけでなく、テクノロジーがビジネス思考を促し、新たな収益源を生み出すことを可能にすることが分かりました。
プロジェクトよりもプロダクト
ソフトウェアプロジェクトは、ソフトウェア開発の資金調達と組織化の一般的な方法です。それらは作業を一時的なビルド専用のチームに組織化し、ビジネスケースで予測された具体的な利点を用いて資金提供されます。一方、プロダクトモードは、持続的なビジネス課題に取り組む持続的なアイデア創出・構築・運用チームを使用します。プロダクトモードでは、チームは迅速に方向転換し、エンドツーエンドのサイクルタイムを短縮し、アーキテクチャの整合性を維持しながら、短期サイクルの反復を使用して実際の利点を検証し、長期的な有効性を維持することができます。
アーキテクトエレベーター—上層階への訪問
多くの大きな組織では、IT エンジンがエグゼクティブペントハウスから多くの階層で分離されており、ビジネスとデジタル戦略も、それを実行するための重要な作業から分離されています。アーキテクトの主要な役割は、ペントハウスとエンジンルームの間をエレベーターに乗って移動し、これらのデジタル活動を支援するために必要な場所で停止することです。ソフトウェア製造の自動化、事前意思決定の最小化、テクノロジーの進化に合わせた組織への影響などです。
リーンエンタープライズにおけるエンタープライズアーキテクトの役割
組織がアジャイルな考え方を取り入れる場合、エンタープライズアーキテクチャは消えるわけではありませんが、エンタープライズアーキテクトの役割は変化します。エンタープライズアーキテクトはもはや選択を行うのではなく、他者が正しい選択を行うのを支援し、その情報を伝達します。エンタープライズアーキテクトは依然としてビジョンを形成する必要がありますが、学習コミュニティを構築するためにチーム間の橋渡しを行う必要があります。これにより、チームは新しいアプローチを探求し、互いに学び合うことができ、エンタープライズアーキテクトはその成長におけるパートナーとなります。
RESTを使用したエンタープライズ統合
ほとんどの内部REST APIは、単一の統合ポイントのために特別に構築された一度限りのAPIです。この記事では、非公開APIで利用できる制約と柔軟性、および複数のチームにわたる大規模なRESTful統合を行うことから得られた教訓について説明します。