ソフトウェアアーキテクチャガイド

前置き

ソフトウェア業界では、人々が「アーキテクチャ」について語る時、ソフトウェアシステムの内部設計の最も重要な側面を曖昧に定義する概念を指します。良好的なアーキテクチャは重要です。そうでなければ、将来的に新機能を追加するのがますます遅くなり、コストも高くなります

しかし「アーキテクチャ」という言葉は慎重に扱うべきです。通常はプログラミングからの分離、さらには派手な誇張を意味するからです。私たちが本当に注目しているのは、自身の変遷をサポートでき、プログラミングと密接に結びついている良いアーキテクチャです。では：

• 良いアーキテクチャとはどのようなものか？

• チームはどのようにして良いアーキテクチャを創造できるか？

• どのようにして私たちの開発組織内でアーキテクチャ思考を育成するか？

一.アーキテクチャとは何か？

アーキテクチャの定義は、ソフトウェア業界で常に議論が続いている話題です。有人认为アーキテクチャはシステムの基本組織方式であり、也有人认为是最高層コンポーネントを一緒に接続する方式。しかし、「基礎」、「高レベル」の客観的定義とは何でしょうか？したがって、より良い見方は専門家開発者がシステム設計に対して形成するコンセンサスです

P.S.もう一つの一般的な定義があり、アーキテクチャはプロジェクト早期に行うべき設計決定だと考えるが、これも十分に正確ではありません。プロジェクト内でできるだけ早く行うべき決定を希望しているように見えるからです

Ralph Johnson は、アーキテクチャとは重要なものすべてである。それが具体的に何であれ と考えています：

Architecture is about the important stuff. Whatever that is.

少し古風听起来ですが、道理があります。アーキテクチャの観点から考慮する核心は、何が重要なものか（つまり、何がアーキテクチャか）を確定し、その後これらのアーキテクチャ要素が良好な状態を維持するように精心を投入することだからです。アーキテクトになりたい開発者にとって、それらの重要な要素、および制御しないと深刻な結果を招く要素を識別できる必要があります

P.S.アーキテクチャ定義に関する詳細情報は、Who Needs an Architect? を参照

二.なぜアーキテクチャはそれほど重要なのか？

ソフトウェア製品の顧客とユーザーにとって、アーキテクチャは厄介な問題です。彼らが即座に感知できるものではないからです。しかし、糟糕なアーキテクチャは杂乱無章（cruft）を促進する主要因であり、これらのものは開発者がソフトウェアを理解するのを妨げます。大量の杂乱なものを含むソフトウェアは変更が難しく、機能イテレーション速度の低下、欠陥の増加につながります：

さらに深刻なのは、これらの杂乱なものがコードベース全体に広がっており、機能イテレーションのたびに遅延させる ことです

習慣経験は告诉我们、通常高品質のものはコストも高いと。ソフトウェアのいくつかの側面（例えばユーザー体験）については、確かにそうですが、アーキテクチャと内部品質の他の側面に関わる時、この関係は正反対です：高内部品質は新機能のデリバリー速度を加速します。杂乱なものからの阻碍が減少するからです

確かに、短期的にはより迅速なデリバリーのために品質を犠牲にできますが、杂乱なものが蓄積��れて影響を及ぼす前に、人々はそれが全体のデリバリーを遅延させる迅速さを過小評価しています。客観的に測定することはできませんが、経験豊富な開発者は知っています。内部品質への注目は何週間以内で報われます（何ヶ月ではなく）

高内部品質のソフトウェアは前期デリバリーが遅いが、後期デリバリー速度ははるかに速い

P.S.ソフトウェア内部品質とコストに関する詳細情報は、Is High Quality Software Worth the Cost? を参照

三.アプリケーションアーキテクチャ

ソフトウェア開発における重要な決定は、私たちが考慮するコンテキスト範囲によって異なります。一般的な範囲はアプリケーション、つまりアプリケーションアーキテクチャです

ソフトウェアアーキテクチャを定義する最初の問題は、アプリケーションとは何かを明確に定義していないことです。本質的に、アプリケーションは一種の社会構造と理解できます：

• 開発者から見ると（アプリケーションは）一堆のコード

• ビジネス顧客から見ると一組の機能

• 投資家から見ると一つの予算計画

この緩やかな定義により、規模が大小さまざまなアプリケーションが存在し、開発チームは数人から数百人まで異なります（規模を関与する人数と見なすのが最も有用な衡量方式です）。企業アーキテクチャとの主な違いは、社会構造を巡って很大程度の統一目標が存在することです

アプリケーションの境界

ソフトウェア開発で未解決の問題の一つは、ソフトウェアの境界が何かを確定することです。例えば、ブラウザはオペレーティングシステムの一部か？

本質的に、アプリケーションは社会構造であり、私たちは数百の異なる方法でソフトウェア境界を描画できます（開発者、ビジネス顧客、投資家などの視点）。多くの面で、これらの境界は人間関係と政治によって划定されており、技術と機能上の考慮に基づいているわけではありません

P.S.詳細情報は、ApplicationBoundary を参照

マイクロサービスパターン

マイクロサービスアーキテクチャパターンは、単一のアプリケーションを一連の小型サービスに分解して開発する方法です。各小サービスは独自のプロセスで実行され、軽量級メカニズム（通常は HTTP リソース指向 API）を通じて通信します。これらのサービスはビジネス機能を巡って構築され、完全に自動化されたデプロイメカニズムによって独立してデプロイされ、異なる言語で記述でき、異なるデータ保存技術を使用でき、最小限の集中管理のみが必要です

これらの利点により、マイクロサービスパターンは過去数年で非常に人気になりましたが、分散コストの増加、一貫性の弱化、および操作管理上の成熟度要求などの代価も随之而来します

P.S.詳細情報は、マイクロサービスアーキテクチャ（Microservices） を参照

Serverless アーキテクチャ

Serverless アーキテクチャは、第三者 BaaS（Backend as a Service）サービスを含み、FaaS（Functions as a Service）プラットフォームでホストされる一時的なコンテナで実行されるカスタムコードを含むアプリケーション設計です。これらの思想とシングルページアプリケーションなどの関連思想を運用することで、このアーキテクチャは伝統的な常に実行されているサーバー側コンポーネントの大部分の需要を消除します

Serverless アーキテクチャは運営コスト、複雑さ、エンジニアリングデリバリーサイクルを大幅に削減するのに役立ちますが、代価はサプライヤーへの依存の増加と相対的に未成熟なサポートサービスです

P.S.詳細情報は、バークレー研究者たち眼中的 Serverless Computing、Serverless Architectures を参照

マイクロフロントエンドパターン

フロントエンド開発をうまく行うのは難しく、フロントエンド開発を拡張して複数のチームが同時に大而複雑な製品を処理できるようにするのはさらに困難です

マイクロフロントエンドパターンは近年出現した、フロントエンド全体を多くの管理しやすい小块に分解し、フロントエンドチームの効率を向上させる流行トレンドです

P.S.詳細情報は、Micro Frontends を参照

GUI アーキテクチャ

最初のフォーム加コントロールから、後年の MVC、MVP などのパターンまで、UI アーキテクチャも不断に進化しています

P.S.詳細情報は、GUI Architectures を参照

表現 - 領域ロジック - データ分层

情報が豊富なプログラムにとって、最も一般的なモジュール化方法は 3 層に分けることです：

• 表現層（UI）

• 領域ロジック層（またはビジネスロジック層と呼ぶ）

• データアクセス層

したがって、Web アプリケーションは HTTP リクエストを処理し HTML をレンダリングする Web 層、検証と計算を含むビジネスロジック層、およびデータベースまたはリモートサービスで永続化データを管理するデータアクセス層に分かれることがよくあります：

分层の最大の利点は関心範囲を狭めることで、これら 3 つの部分を個別に考慮できます。モジュール境界を確立したため、異なる実装に切り替える影響範囲が比較的小さくなり、独立してテストしやすくなります

P.S.詳細情報は、Presentation Domain Data Layering を参照

四.企業アーキテクチャ

アプリケーションアーキテクチャは何らかの形式的な概念的アプリケーション境界内のアーキテクチャに焦点を当てますが、企業アーキテクチャは企業全体を見渡すアーキテクチャです。企業組織は通常大きすぎて、すべてのソフトウェアを凝集方式で分割できないため、各自が多くのコードベースを持つチームを調整する必要があります。これらのチームは互いに独立して開発し、資金とユーザーも独立して運用します

企業アーキテクチャの多くの内容はどのような中心化調整が価値があるか、および調整はどのような形式を取るべきかに関するものです。一つの極端な状況は中心化アーキテクチャ分割で、企業下の各ソフトウェアシステムのすべてのアーキテクチャ決定を承認する必要があります。この分割は決定速度を遅くし、広範���システム組合せ内のさまざまな問題を本当に理解できず、決定不力につながります。もう一つの極端は完全に調整がなく、チームの重複作業、異なるシステム間の相互運用不能、チーム間のスキル育成と交叉学習の欠如につながります

これに対して、束縛的な制御を行うよりも、権限を下放し、同時に局所決定をできるだけ強化し、関与する実際コストを最小限に抑えるべきです

企業アーキテクトを開発チームに参加させる

企業アーキテクチャグループは通常日常開発と分離されており、これにより彼らの開発作業に対する認知が時代遅れになり、開発チームも全会社の広範な視点から見ていません。したがって、企業アーキテクトは開発チームに参加することで効率を向上できるかもしれません

P.S.詳細情報は、Enterprise Architects Join the Team を参照

リーン企業における企業アーキテクトの役割変化

企業がアジャイル思考を採用する時、企業アーキテクチャは消失しませんが、企業アーキテクトの役割は変化します：

• 企業アーキテクトは選択を行わなくなり、代わりに他人が正しい決定を行うのを支援し、その後これらの情報を伝播する

• 企業アーキテクトは依然としてビジョンを形成する必要があるが、その後チーム間に橋を架け、学習コミュニティを構築する

• 企業アーキテクトはチームとパートナーシップを構築し、成長の中で新しい方法を探索し相互に学習する

P.S.詳細情報は、The Role of an Enterprise Architect in a Lean Enterprise を参照

製品パターンはプロジェクトパターンに勝る

プロジェクトパターンは、ソフトウェアプロジェクトに従って資金投入とソフトウェア開発を組織化する流行方式です。仕事を一時的な、実装のみを担当するチームに組織化し、ビジネスシナリオで予想される特定の収益によって資金提供されます

製品パターンは代わりに永続的な、構想・実装・運行を担当するチームに切り替え、持続的に存在するビジネス問題を解決します。製品パターンはチームが迅速に方向を調整し、エンドツーエンドのサイクル時間を削減し、短サイクルイテレーションを通じて実際の収益を検証し、同時にソフトウェアアーキテクチャの完全性を維持してその長期有効性を保証することを可能にします

P.S.詳細情報は、Products Over Projects を参照

アーキテクトの責務

多くの大規模組織の IT 部門と決定権を持つ高層の間には多くの階層が隔てられており、これもビジネスとデジタル戦略と戦略を実施する重要な作業を分離しています

したがって、アーキテクトの主要な責務は顶层から機房までのエレベーターに乗り、デジタル作業をサポートする必要があるあらゆる場所で停止することです：ソフトウェア生産を自動化し、前期決定を最小限に抑え、技術進化と同時に組織に影響を与える

P.S.詳細情報は、The Architect Elevator — Visiting the upper floors を参照

参考資料

• Software Architecture Guide