エクストリームプログラミングに少し触れたことがある人にとって、XPはソフトウェア設計の死を意味するように見えるかもしれません。多くの設計活動は「Big Up Front Design」として嘲笑されるだけでなく、UML、柔軟なフレームワーク、さらにはパターンといった設計手法も軽視されたり、完全に無視されたりします。実際、XPは多くの設計を伴いますが、確立されたソフトウェアプロセスとは異なる方法で行われます。XPは、進化を現実的な設計戦略にすることを可能にするプラクティスによって、進化型設計の概念を活性化しました。また、シンプルな設計の方法、リファクタリングによる設計のクリーンな状態の維持、パターンを進化的なスタイルで使用するなど、設計者にとって新たな課題とスキルをもたらします。

過去10年間、アプリケーションの開発に伴ってデータベース設計を進化させるための多くの手法を開発・改良してきました。これはアジャイル手法にとって非常に重要な機能です。これらの手法は、継続的インテグレーションと自動化されたリファクタリングをデータベース開発に適用し、DBAとアプリケーション開発者の緊密な連携によって実現されます。これらの手法は、本番前システムとリリース済みのシステムの両方、グリーンフィールドプロジェクトとレガシーシステムの両方で機能します。

既存のソフトウェアシステムを置き換える必要に直面した場合、組織はしばしば半ば完成したテクノロジー置換のサイクルに陥ります。私たちの経験から、このサイクルを打破するためのパターンをいくつか学びました。それは、レガシーソフトウェアを置き換えることで期待される成果を意図的に認識し、この置換を部分的に分割し、これらの部分を段階的に提供し、変化が不変の現実であることを認識するよう組織の文化を変えることです。

アーキテクチャは、中心的な少数の人の頭脳と口からトップダウンで伝えられる独り言である必要はありません。この記事では、分散型で権限委譲型の意思決定手法によって推進され、意思決定記録、諮問フォーラム、チーム主導の原則、テクノロジーレーダーという4つの学習と調整メカニズムによってサポートされる、アーキテクチャを行う別の方法について説明します。

近年、スキーマレスデータの利点に関する議論が増えています。スキーマレスであることは、NoSQLデータベースへの関心の主な理由の1つです。しかし、データベースとメモリ内データ構造の両方において、スキーマレスには多くの微妙な点があります。これらの微妙な点は、スキーマレスの意味、およびスキーマレスアプローチを使用することの利点と欠点の両方において存在します。

最近、私の同僚であるニール・フォード、レベッカ・パーソンズ、パット・クアが「進化型アーキテクチャの構築」というタイトルの本を書きました。彼らが私に序文を書いてくれるよう依頼してくれたことを光栄に思います。

私の著作を読んだことがある読者なら、私が進化型設計の熱心な支持者であることを知っているでしょう。このアプローチへの熱意にもかかわらず、完璧な手法はなく、成功だけでなくその問題についても喜んで報告します。

資産取得は、StranglerFigアプリケーションを開発するための戦略です。多くのアプリケーションは、主要な資産セットの管理と考えることができます。給与計算システムは従業員を管理し、取引システムは取引を管理し、リースシステムはリースを管理します。新しいシステムに徐々に移行するには、新しいシステムから開始する資産のサブセットを特定することから始めることができます。多くの場合、最初に開始するのに最適な資産は、単純な資産（迅速に開始できるため）か、古いシステムでは処理が特に困難なニーズを持つ資産です。

ソフトウェアを適切に設計するだけの価値はあるのでしょうか？

ドメイン駆動設計とは、ドメインのプロセスとルールを深く理解したドメインモデルのプログラミングを中心としたソフトウェア開発アプローチです。この名称は、このアプローチをパターンのカタログを通して説明したエリック・エヴァンスによる2003年の著書に由来します。それ以来、実践者コミュニティがさらにアイデアを発展させ、さまざまな書籍やトレーニングコースを生み出しました。このアプローチは、多くの複雑で混乱しやすいロジックを整理する必要がある、複雑なドメインに特に適しています。

SOAはアジャイルアプローチで実現できますか？

私がマイクロサービスアーキテクチャを使用するチームに関する話を聞いていると、共通のパターンに気づきました。

1. 成功したマイクロサービスのほとんどすべては、大きくなりすぎて分割されたモノリスから始まっています。
2. 最初からマイクロサービスシステムとして構築されたシステムについて聞いたほとんどの場合、深刻な問題に陥っています。

このパターンにより、多くの同僚は、**アプリケーションが大きくなるほど価値があると確信していても、マイクロサービスで新しいプロジェクトを開始すべきではない**と主張するようになりました。

多くの組織では、永続的なデータは、中央データベース管理グループによって管理されるリレーショナルデータベースに格納されることが期待されています。このような中央管理にはさまざまな理由があり、通常は統合データベースの使用を中心としています。中央データグループは、不正なデータ、重要な共有リソースを遅くする可能性のあるクエリ、および企業全体での一貫性のあるデータモデルの排除を懸念しています。

これらの目的は価値のあるものかもしれませんが、その結果として、データの保存に関する多くの儀式が発生します。データベースに列を追加するのに数週間かかる変更依頼に関する苦情をよく耳にします。短サイクルの進化型設計に慣れている最新のアプリケーション開発者にとって、そのような儀式は遅すぎますし、イライラするものです。

そのため、アプリケーション開発グループは、DBAを回避するためにNoSQLデータベースを使用していると教えてくれます。「適切なデータベース」ではなく「単なるデータストア」を使用しているためです。このようにして、DBAをループの外に保つことができ、多くの場合、伝えなかったり、気にしないことに満足したりします。

すべてのコンシューマーに影響を与えるインターフェースへの変更を行うには、変更自体の実装と、そのすべての使用方法の更新という2つの思考モードが必要です。特に、複数のクライアントまたは外部クライアントを持つ公開インターフェースで変更を行う場合、同時に両方を行うのは困難です。

**並列変更**（**拡張と縮小**とも呼ばれます）は、拡張、移行、縮小という3つの明確なフェーズに分割することにより、安全な方法でインターフェースへの後方互換性のない変更を実装するためのパターンです。

会議に座って、チームが過去2年間取り組んできたコードを検討しています。現在できる最善の策は、そのコードをすべて破棄して、まったく新しいアーキテクチャで再構築することだと結論付けました。その運命づけられたコード、それに費やした時間、そして過去に行った決定について、どう感じますか？

オブジェクト指向の黎明期、私のようなオブジェクト指向の提唱者は、再利用を促進することに多くの注意を払っていました。当初はクラスの再利用について議論していました。しかし、個々のクラスの再利用は、いくつかのケースではうまく機能しましたが、他のケースではうまく機能しませんでした。そこで、再利用可能なフレームワークに取り組み始め、部分的に構築された機能を持つアプリケーションを手に入れるようになりました。

Webサービスを使用する利点の1つは、システムのさまざまな部分をデカップリングできることです。人々は、ある程度の分離を保ちながら、別々のコードベースで作業できます。ある程度のデカップリングは実現できますが、サービスは依然としてインターフェースを介して互いに通信する必要があるため、カップリングを完全に排除することはできません。悲しいことに、多くのチームがこのカップリングを必要以上に悪化させています。

Yagniはもともと「You Aren't Gonna Need It（必要ないだろう）」の頭字語です。エクストリームプログラミングのモットーであり、アジャイルソフトウェアチームで一般的に使用されています。これは、将来ソフトウェアが必要になると想定している機能は、"必要ないだろう"ため、今は構築すべきではないという主張です。