「マイクロサービスアーキテクチャ」という用語は、ここ数年で、ソフトウェアアプリケーションを独立してデプロイ可能なサービスのスイートとして設計する特定の方法を説明するために登場しました。このアーキテクチャスタイルには正確な定義はありませんが、ビジネス能力を中心とした組織化、自動デプロイメント、エンドポイントでのインテリジェンス、言語とデータの中央化されていない制御など、いくつかの共通の特性があります。

Javaコミュニティでは、異なるプロジェクトのコンポーネントをまとまりのあるアプリケーションに組み立てるのに役立つ軽量コンテナが急増しています。これらのコンテナの根底には、配線を実行する方法に関する共通のパターンがあり、それらは非常に一般的な名前である「制御の反転」という概念で参照しています。この記事では、このパターンがより具体的な名前である「依存性注入」の下でどのように機能するかを掘り下げ、サービスロケーターの代替案と比較します。どちらを選択するかは、構成と使用を分離するという原則よりも重要ではありません。

サーバーレスアーキテクチャは、サードパーティの「Backend as a Service」（BaaS）サービスを組み込んだアプリケーション設計、および「Functions as a Service」（FaaS）プラットフォーム上の管理された一時的なコンテナで実行されるカスタムコードを含むアプリケーション設計です。これらのアイデアと、シングルページアプリケーションのような関連するアイデアを使用することで、このようなアーキテクチャは、従来の常時オンサーバーコンポーネントの必要性の多くを取り除きます。サーバーレスアーキテクチャは、ベンダーへの依存性の増加と比較的未熟なサポートサービスを代償に、運用コスト、複雑さ、およびエンジニアリングリードタイムを大幅に削減できる可能性があります。

エクストリームプログラミングに触れた多くの人にとって、XPはソフトウェア設計の死を求めているように思えます。多くの設計活動が「Big Up Front Design」として嘲笑されるだけでなく、UML、柔軟なフレームワーク、さらにはパターンなどの設計技術も強調されなかったり、完全に無視されたりします。実際、XPには多くの設計が含まれていますが、確立されたソフトウェアプロセスとは異なる方法で行われます。XPは、進化を実用的な設計戦略にするプラクティスによって、進化的設計の概念を活性化させました。また、設計者は、シンプルな設計を行う方法、リファクタリングを使用して設計をクリーンに保つ方法、進化的スタイルでパターンを使用する方法を学ぶ必要があり、新たな課題とスキルを提供します。

RESTアプローチの主要な要素を3つのステップに分解したモデル（レナード・リチャードソンによって開発されました）。これらは、リソース、http動詞、ハイパーメディアコントロールを導入します。

フィーチャートグル（フィーチャーフラグとも呼ばれることが多い）は、コードを変更せずにシステムの動作を変更できる強力なテクニックです。それらはさまざまな使用カテゴリに分類され、トグルを実装および管理するときは、その分類を考慮に入れることが重要です。トグルは複雑さを導入します。スマートなトグル実装プラクティスと、トグル構成を管理するための適切なツールを使用することで、その複雑さを抑制できますが、システム内のトグルの数を制限することも目指すべきです。

「モックオブジェクト」という用語は、テストのために実際のオブジェクトを模倣する特殊なオブジェクトを説明するために一般的なものになりました。ほとんどの言語環境には、モックオブジェクトを簡単に作成できるフレームワークがあります。しかし、しばしば認識されていないのは、モックオブジェクトが特殊なテストオブジェクトの一形態にすぎず、異なるスタイルのテストを可能にするということです。この記事では、モックオブジェクトがどのように機能するか、動作検証に基づいたテストをどのように奨励するか、およびそれらを取り巻くコミュニティがそれらを使用して異なるスタイルのテストを開発する方法について説明します。

継続的インテグレーションは、チームの各メンバーが自分の変更を、同僚の変更とともに、少なくとも毎日コードベースにマージするソフトウェア開発プラクティスです。これらの各インテグレーションは、できるだけ早くインテグレーションエラーを検出するために、自動化されたビルド（テストを含む）によって検証されます。チームは、このアプローチによって、デリバリーの遅延リスクが軽減され、インテグレーションの労力が軽減され、新しい機能による迅速な拡張に適した健全なコードベースを育成するプラクティスが可能になることを発見しています。

ここ数年で、サービスベースのアーキテクチャは、より小さく、より焦点を絞った「マイクロ」サービスへと移行しています。このアプローチには、各コンポーネントを独立してデプロイ、スケーリング、保守できることや、複数のチーム間で開発を並行化できるなど、多くのメリットがあります。ただし、これらの追加のネットワークパーティションが導入されると、モノリシックなインプロセスアプリケーションに適用されていたテスト戦略を再検討する必要があります。ここでは、複数の独立してデプロイ可能なコンポーネントの追加のテストの複雑さを管理するための多くのアプローチと、複数のチームがそれぞれ異なるサービスの保護者として行動しているにもかかわらず、テストとアプリケーションを正しく維持する方法について説明する予定です。