基本的に、それは勧告に仕上げ、従来のソフトウェア開発methologiesの説明、およびアジャイル方法論のその後の誕生を開始します、私は私の卒業論文を始めていますし、被写体が「アジャイルアーキテクチャ」アジャイルアーキテクチャ
となり、ソフトウェア構築における固有の変化に容易に適応可能な柔軟なアプリケーションアーキテクチャの設計。
私の質問は、このようなアーキテクチャにどのようなパターンやデザインプラクティスをお勧めしますか？ 私は、依存性注入、高いメンテナンス性、特定の問題からの最大抽象化のようなクラスのデカップリングの最大化を可能にするパターンに興味があります。
私は次のことをお勧めします：基本的に
ALT.NETの観衆が説教すべて。
確かに一般的にIoCの慣行や契約ベースプログラミングは私のリストの一番上になります。しかし、経験の問題から、私は抽象化のために問題をあまりにも抽象化することに注意する。例えば。誰もがその抽象化を利用できるようになるためではなく、抽象化することができます。私は、この種のアーキテクチャが悪くなったのを見て、単にシステムに複雑さを高めすぎて、システムのメンテナンスを悪化させてしまったのです。
ユニットテスト、継続的な統合、および/または "スクラム"ミーティングのような、開発プロセスの周りのある種のフィードバックループ。実際にはアジャイルな「アーキテクチャ」の範囲に入るわけではありませんが、アジャイルプロセスがなくても、「アジャイル指向」アーキテクチャの程度は重要ではありません。
これは興味深い質問です。アーキテクチャを孤立してアジャイルにすることはできますか？私たちがXPのようなものを見ているなら、私はちょっと疑問に思います。または、私が誤解したことはありませんが、それは決して私を拡大から止めません...
XPでは、プロジェクトを開始する。実際には最初のストーリーが完成する頃です。最初のストーリーライティングでは、構築することを考え始めました。プログラマーはコードの点で考える傾向があります。しかし、あまりにも先に考えてみると、私たちはYAGNIになります。
アジャイルな環境で開発されたアプリケーションのアーキテクチャーの多くは、特に重複を排除するための定数と専用のリファクタリングによって創出されると考えられています。
おそらく、アジャイルプロセスの結果として進化したアーキテクチャが表示される傾向がある特定の特性（または特性のクラス）があるかどうかを評価することは多分問題です。そして、私はそれがすでに述べたいくつかの原則（私が理解しているもののいくつか）は可能性があるにもかかわらず、それが我々が構築しているアプリケーションの種類に依存すると思う。
アジアルは、「アーキテクチャ」をそのように宣言していないと思っています。アジャイルは、プロジェクト管理、リリースサイクル、一般的な開発慣行に影響する基本原則に基づいているが、確かにソフトウェアアーキテクチャーではない方法論です。
ここに記載されているすべてのソフトウェアパターンは、アジャイル開発で困惑している強力なウォーターフォールプロセスを使用して使用できます。
あなたは変化を受け入れるアジャイルの手段なので、つまりは、要件と設計上の決定に変更し、などをリファクタリング受け入れるために採用..あなたがしているので、多くの「伝統的」な方法は、時に難色を示すだろう働いている/以前に同意したことに触れている。
XPのような方法では、単体テストを書くことによって高品質を維持しようとします。単体テストの作成に全員が同意したとしよう。
ここでは、すべてのシステムがテスト可能なわけではないため、システムがテスト可能またはテストにやさしいアーキテクチャを紹介します。たとえば、中間層を呼び出し可能にし、ビジネスロジックなどとは別のUIレイヤを作成する。
機能のエンドツーエンドのアーキテクチャを最初に構築することをお勧めします。 実際のフィードバックによって可能な限り早期に検証する。
これは、Pragmatic Programmersが "Tracer Bullets"、Alistair Cockburnを "walking skeleton"と呼びます。
あなたの論文の文脈にアプリケーションが何であるかを定義することはできますか？ application softwareまたは と考えるだけで、もっと複雑なシステムも扱っていますか？
ロバート・マーティンがそれについて（そしてアジャイル・マニフェスト・ミーティングIIRCと呼んだ）何かを語っているならば、絶対的なアーキテクチャーには敏捷性があります。彼の本Agile Software Development, Principles, Patterns, and Practicesの最初のセクション全体は、SOLIDアーキテクチャの原則です。これはいくつかの四半期では幾分議論の余地がありましたが、私は理由を理解していません。コードベースが脆弱で強く結合されている場合、変更するのは非常に難しくありません。これは敏捷性の特徴です。概念的には、コード実行からプロセスを分離することは、非常に非機敏なことです。
マニフェストの原則1：「私たちはプロセスとツールに対する個人や介入を重視しています。」
コードベースのアーキテクチャーとは別の抽象としての私のアジャイルな「プロセス」の定義は、この第1の原則の精神に反します。