アジャイルアーキテクチャ [終了]

Question

私は卒業論文を書き始めていますが、テーマは「アジャイルアーキテクチャ」です。

基本的には、従来のソフトウェア開発手法の説明とその後のアジャイル手法の誕生から始まり、ソフトウェア構築における固有の変化に簡単に適応できる柔軟なアプリケーション アーキテクチャの推奨事項と設計で終わります。

私の質問は、そのようなアーキテクチャに対してどのようなパターンと設計手法を推奨するかということです。私は、依存関係の注入、高い保守性、特定の問題からの最大限の抽象化など、クラスの分離を最大限に可能にするパターンに興味があります。

Answer 1

以下をお勧めします。

1. リポジトリパターン
2. 仕様パターン
3. 依存関係の注入
4. ドメイン駆動設計

基本的には、ALT.NET の人々が説いているすべてのことです。

Answer 2

間違いなく IoC の実践と 契約ベースの プログラミング全般が私のリストの一番上にあります。ただし、経験上、抽象化するためだけに問題からあまりにも抽象化しないように注意したいと思います。例えば。抽象化するのは、あなたができるからであり、誰もがその抽象化を利用できるからではありません。私は、その種のアーキテクチャが悪化し、単にシステムに過度の複雑性を追加して、システムのメンテナンスを悪化させているのを見てきました。

単体テスト、継続的インテグレーション、「スクラム」ミーティングなど、開発プロセスの周囲にある種のフィードバック ループが存在します。これは実際にはアジャイルな「アーキテクチャ」の範囲に当てはまらないことは承知していますが、アジャイルなプロセスがない場合、「アジャイル指向」アーキテクチャの程度は問題になりません。

Answer 3

私が提案する本質的な設計プラクティスは、まず機能的でエンド・ツー・エンドなものを構築することだ。 建築の骨格。実際のフィードバックによってできるだけ早く検証すること。

これは、実用的なプログラマーが「トレーサー弾丸」と呼び、アリスター・コックバーンが「」と呼んでいるものです。歩く骸骨".

また、アプリケーションの定義も教えてほしい。 あなたの論文の文脈は？だけ考えてますか？ アプリケーションソフトウェア または もっと複雑なシステムも扱っているのですか？

Answer 4

興味深い質問ですね、これは。アーキテクチャを単独でアジャイルに作成できますか?XP のようなものを検討している場合は、少し疑問です。あるいは、私が誤解しているのかもしれませんが、それでも私は拡張を止められませんでした...

XP では、私がよく知っているアプローチを採用すると、プロジェクトを開始してから非常に短期間で、ある種の構造を構築することになります。実際、最初のストーリーが完了した頃です。最初のストーリー執筆中に、何を構築するかについてある程度のアイデアを得るようになります。これは避けられません。プログラマーはコードの観点から考える傾向があります。しかし、あまりにも先のことを考えすぎると、 ヤグニ 地域。

私は、アジャイル環境内で開発されるアプリケーションのアーキテクチャの多くは、特に重複を除去するための継続的かつ専用のリファクタリングを通じて出現することが期待されるのではないかと考えていました。

したがって、おそらく問題は、アジャイル プロセスの結果として進化したアーキテクチャが示す傾向にある特定の特性 (または特性のクラス) があるかどうかを評価することと同じくらい重要です。そして、それは私たちが構築するアプリの種類によって決まると思いますが、すでに述べた原則のいくつか（そのうちのいくつかは私も理解しています）はおそらく当てはまります。

Answer 5

私の知る限り、アジャイルは「アーキテクチャ」そのものを説いているわけではありません。アジャイルは、プロジェクト管理、リリース サイクル、一般的な開発慣行に影響を与える基本原則に基づいた方法論ですが、ソフトウェア アーキテクチャではありません。

ここにリストされているソフトウェア パターンはすべて、アジャイル開発にとって忌まわしい強力なウォーターフォール プロセスを使用して使用できます。

Answer 6

オニオン建築

例

Answer 7

アジャイルであるということは、変化を受け入れることを意味します。要件の変更や設計上の決定を受け入れ、リファクタリングなどを受け入れます。機能している/以前に合意されたものに触れているので、「伝統的な」方法では多くのことに眉をひそめます。

XP のような方法では、単体テストを作成することで品質を高く維持しようとします。単体テストの作成について全員が同意しているとしましょう。

すべてのシステムがテスト可能であるわけではないため、ここでシステムをテスト可能またはテストしやすいようにアーキテクチャを導入できます。たとえば、中間層を呼び出し可能にし、UI 層をビジネス ロジックから分離するなどです。

Answer 8

Robert Martin がそれについて何か言いたいことがあれば (そして彼は IIRC 会議で最初のアジャイルマニフェストを呼び出しました)、間違いなくアーキテクチャはアジャイルにすべて関係しています。彼の本の最初のセクション全体 アジャイル ソフトウェア開発、原則、パターン、実践 についてです 固体 建築上の原則。これは一部で物議をかもしていますが、私にはその理由がわかりません。コードベースが脆弱で結合度が高い場合、変更をあまり受け入れることができません。これが俊敏性の特徴です。プロセスをコードの実践から概念的に分離することは、非常に非アジャイルな行為です。

マニフェストの原則 1:「私たちはプロセスやツールよりも個人と交流を重視します。」

私にとって、アジャイルの「プロセス」をコードベースのアーキテクチャとは別の抽象化として定義することは、この第一原則の精神に違反します。