アジャイル環境でアーキテクチャ設計はどのように行われますか？

アジャイルアーキテクトの原則を読んで、次の原則を定義しました。

原則＃1システムをコーディングするチームがシステムを設計します。
原則＃2動作する可能性のある最も単純なアーキテクチャを構築します。
原則＃3疑わしい場合は、コーディングします。
原則＃4構築し、テストします。
原則＃5システムが大きいほど、滑走路は長くなります。
原則＃6システムアーキテクチャは役割のコラボレーションです。
原則＃7イノベーションに関する独占権はありません。

この論文では、アーキテクチャ設計の大部分はコーディング段階で行われ、その前のシステム設計のみが行われると述べています。それは結構です。

それでは、システム設計はどのように行われますか？UMLを使用していますか？または、インターフェイスと主要なブロックを定義するドキュメントですか？たぶん何か他に？

免責事項：私は機敏な環境の建築家ですが、ヘルムート・フォン・モルトケ・ザ・エルダーが言うように、「敵との接触で生き残る戦いの計画はありません」。言い換えれば、実用性は、ガイドラインの正確な文字が常に従うことができないことを意味します。

上記のポイントのほとんどは、チームができる限り最善を尽くしています。ただし、原則1（システムをコーディングするチームがシステムを設計するチーム）は、チームが異なる大陸やタイムゾーンに分割された数十（または数百）の開発者で構成される場合、従うのが非常に困難です。これは、開発者のスキルや態度とは関係ありません。顧客からの要件を収集し、既存の複雑なシステムを理解するために、すべての開発者のロジスティック問題が存在します。

それでは、システム設計はどのように行われますか？UMLを使用していますか？または、インターフェイスと主要なブロックを定義するドキュメントですか？たぶん何か他に？

多くの場合、アーキテクトは主要コンポーネントを特定し、それらの間のインターフェース（セキュリティ、速度、信頼性などの非機能要件を含む）を定義し、コンポーネントの内部設計を個々のチームに委任します。これは、チームがシステムに関するすべてのことを知る必要なく、独自のコンポーネントを設計できるようにすることの良い妥協点です。

すべての組織には、アーキテクチャ設計のための独自の標準セットがあり、これは組織内のプロジェクトごとに異なる場合があります。この設計は、チームがコーディングを開始する前、または可能な限り早期に行われ、通常は含まれています（完全なリストではありません）。

1. 拡張された要件とスコープ定義。これらには、より高いレベルのビジネス要件を具体化するユースケースまたはユーザーストーリーが含まれます。個人的には、機能以外の要件にはRFC 2119を使用したいと思っています。設計はこれらに基づいており、これらにまでさかのぼります。設計の一般的な定義に合わないかもしれませんが、これらはしばしば同じくらい重要です。
2. 高レベルのネットワーク図またはコンポーネント図とテキストのページで構成される概要。これは、上級管理職から開発者およびQAまで、非常に幅広い読者を対象としています。対象読者が多いため、UMLまたは定義された表記法を使用することはほとんどありません。
3. 個々のコンポーネントの詳細。多くの場合、前述のように、それらの間のインターフェースまたはAPIに焦点を当てています。インターフェイスは、前提条件と事後条件の詳細を含むターゲット言語のメソッドシグネチャとして指定できます。コンポーネントには、クラウドまたはデータセンター内のVMのレイアウトとそのネットワーク配置を示すようなネットワーク図があります。通常、リレーショナルデータベースにはエンティティ関係図があります。
4. 既知の場合、アーキテクチャ上のリスクとその軽減策のリスト。要件と同様に、これらは設計上の決定とトレードオフを示しています。

つまり、アジャイルプロセスのシステムの設計は、従来のウォーターフォールプロセスの設計とまったく同じです。ただし、アジャイル環境では、事前に行われる設計が少なくなり、コンポーネントチームに委任されます。重要なのは、最初にどれだけ深く行くか、どの決定を延期するかを決定し、いつ決定を行う必要があるかを識別することです。複数の開発チームに影響を与える決定、特にスケーラビリティとセキュリティは、早期に行う必要があります。すでに国際化された製品に言語を追加するなどの決定は、非常に遅くまで延期できます。

初期設計が作成された後、設計者は各チームと協力して設計をレビューします。作業単位（スクラムスプリントなど）に追加の設計または設計変更が必要な場合、アーキテクトは、作業単位が開始されるまでにそれを利用可能にすることを目指しています。アーキテクトは、影響を受けるチームまたは利害関係者に変更を伝える責任も負います。

免責事項：私はアジャイルコーチ/アーキテクトではありません-これは私が取り組んだアジャイルプロジェクトで見たものであり、うまくいくと思います。

アジャイルがアーキテクチャをどのように行うかはアジャイルによって完全に定義されているとは思わない-アジャイルは開発の方法論と実践に焦点を合わせている。一方、UMLは、アジャイルを超えたアーキテクチャを伝えるための単なる言語です（プロジェクトやチームに適合する場合は使用します）。

実際に適用されるアーキテクチャの原則の1つは、責任のある最後の瞬間に決定を下すことです。これは、特にこの段階で情報がほとんどないため、プロジェクトの最初にすべての決定を行っていない場合は問題ありません。時間が経つにつれて、アーキテクチャを「進化させる」決定を下す可能性があります。はい、これはいくつかの手直しのように見えるかもしれませんが、これはまた、環境、要件、可能でないことなどについて新しいことを学んだという事実によるものです。

コードは実際に準拠していない-あなたは避けたい主なものは、アーキテクチャの腐敗である任意の特定のアーキテクチャとちょうどもつれた混乱です。アーキテクチャの進化と比較した場合の主な違いは、後者では、意識的な決定を定期的に行い、明確な理由でそれらを文書化し、その後、コードがそれに従っていることを確認することです。

テスト駆動開発を行うときは、モジュールを分離してテストするテストコードを作成します（=可能な限り他のモジュールに依存しない）

テストコードの作成を容易にするために、簡単にモックアップできる他のモジュールへのインターフェースを導入します。

この方法は、副作用として、モジュール間の結合が可能な限り小さいアーキテクチャを自動的に取得します。

私の意見では、tddは建築作業でもあります。