解説アーキテクチャ

ソフトウェアシステムの理解を深める上での問題点の一つは、十分な数の例を見ることができないことです。多くの専門分野では、人々は既存の成果物を見ることで学びます。事例は、インスピレーション、優れたアイデアの源、そして困難な状況への警告として役立ちます。ソフトウェアに関しては、長い間、この方法で学ぶことは非常に困難でした。

私は、システムがどのように構築されているのかを見ることを常に楽しんでおり、今後さらに時間をかけて、興味深いアーキテクチャを共有していきたいと考えています。これらのアーキテクチャは、モデルハウスや庭園のようなものなので、解説アーキテクチャと呼んでいます。自分の目的には完全に合致しないかもしれませんが、参考にしたい側面が含まれている可能性があります。

この形式の記事のリストについては、解説アーキテクチャタグを参照してください。

「アーキテクチャ」という言葉は非常に曖昧なため、私は通常、この言葉の使用を避けています。この記事では、ラルフ・ジョンソンによる「*重要なもの（それが何であれ）*」という私が好むアーキテクチャの定義に従います。つまり、システム設計について、私自身の判断と開発チームの判断の両方に基づいて、興味深いと思う点について説明します。

「解説」という言葉を使うのは、これらのアーキテクチャが興味深いアイデアの源であり、「ベストプラクティス」のようなものとして意図されていないことを強調するためです。第一に、具体的なシステムを構築する際には考慮すべき変数が非常に多いため、ある種の標準として設定されたアーキテクチャには非常に慎重です。例えば、多くの人がスケーラブルなアーキテクチャ（通常は大量の負荷を処理できる能力を意味します）の重要性を強調しています。しかし、多くの有用なシステムは、高負荷になることのない社内システムであるため、異なる一連の要因をサポートするように設計する必要があります。

うまくいかなかった要因を強調することも有効です。私たちは、うまくいったことを見るだけで学ぶのではなく、うまくいかなかったことも、魅力的な道を避けるための良い指針となることがよくあります。また、アーキテクチャ上の機能の中には、あるチームメンバーには非常に好かれ、他のチームメンバーには嫌われるということがよくあります。何が好意と嫌悪感を駆り立てるのかを理解することで、それが自分のアーキテクチャの美学に合うかどうかを知ることができます。

解説アーキテクチャの記事は、執筆に多くの時間と労力を要するため、頻繁には投稿しません。システムがどのように機能し、どこに面白い部分があるのかを感じ取るには、システムを十分に理解するのに時間がかかります。また、開発チームが物事を説明し、私が何かを誤解していないことを確認するのにも時間と労力が必要です。

私が説明するアーキテクチャのほとんどは、Thoughtworksのプロジェクトから得られると予想しています。なぜなら、私にとってアクセスしやすいからです。しかし、これは絶対的なルールではなく、時間があれば、Thoughtworks以外のプロジェクトで私の目を引くものがあれば、喜んで取り上げます[1]。

私が書く解説アーキテクチャは、すべて少なくとも1つの実際のシステムに基づいています。開発段階ではよく見えても、実際に運用を開始してからしばらくすると状況が変わることが多いため、1年程度運用されているシステムを好みます。しかし、これは絶対的なルールではなく、あくまでも好みです。

アーキテクチャを説明する際には、参照としてアーキテクチャに名前を付けますが、通常、この名前は私の説明のためにつけたもので、システム名はクライアントのコンテキストと密接に結びついているためです。同様に、システムを記述する際には、私がここで書いている他の内容と一致する語彙を使用します。これは、開発チームが実際に使用している用語とは異なる場合があります。