最近の多くのWebサーバーコードは、JSONデータを返すアップストリームサービスと通信し、そのJSONデータを少し変更し、流行のシングルページアプリケーションフレームワークを使用してリッチクライアントWebページに送信します。このようなシステムで作業している人々と話すと、これらのJSONドキュメントを操作するためにどれだけの作業が必要かという不満をよく耳にします。この不満の多くは、読み込み戦略の組み合わせをカプセル化することで回避できます。

多くのプログラミング環境では、データ構造をリストとハッシュマップの複合体として表現するのが一般的です。ほとんどの主要な言語は、これらのデータ構造の標準バージョンと、特にそれらを操作するためのコレクションパイプラインを含む、豊富な操作を提供するようになりました。これらのデータ構造は非常に柔軟性があり、ほとんどの形式の階層を処理および操作しやすい方法で表現できます。

私が執筆活動を始めた頃は、技術雑誌の記事を書いていました。今では、記事の長さの作品を書くときは、すべてWeb向けに書かれています。紙の雑誌はまだ存在しますが、縮小する少数派であり、おそらく絶滅する運命にあります。しかし、紙の雑誌が衰退しているにもかかわらず、紙の雑誌の多くの前提は、依然として作家や出版社を支配しています。これは、私のサイトに公開したい記事に取り組んでいる人々との最近の会話で特に話題になりました。

組織がアジャイルマインドセットを採用する場合、エンタープライズアーキテクチャはなくなるわけではありませんが、エンタープライズアーキテクトの役割は変化します。エンタープライズアーキテクトはもはや選択を行うのではなく、他の人が正しい選択を行うのを助け、その情報を発信します。エンタープライズアーキテクトは依然としてビジョンを形成する必要がありますが、その後、チーム間の橋渡しをして学習コミュニティを構築する必要があります。これにより、チームは新しいアプローチを模索し、互いに学び合うことができます。エンタープライズアーキテクトはその成長のパートナーとなります。

ソフトウェアロジックのほとんどはプログラミング言語で記述されており、これらはロジックを記述および進化させるための最適な環境を提供します。ただし、そのロジックを、命令型コードが解釈できるデータ構造（適応モデルと呼ぶ）に移動すると便利な場合があります。ここでは、JavaScriptの製品選択ロジックを示し、JSONでエンコードされた単純なプロダクションルールシステムにリファクタリングする方法を示します。このJSONデータにより、異なるプログラミング言語を使用するデバイス間でこの選択ロジックを共有し、これらのデバイスのコードを更新せずにこのロジックを更新できます。

リモートワークとコロケーションワークの単純な二分法はなく、代わりに、チームの分散にはいくつかのパターンがあり、それぞれに異なるトレードオフと、それぞれに適した効果的な手法があります。決定的な証拠を決定することは不可能ですが、ほとんどのグループは、コロケーション方式で作業する方が生産性が高いと感じています。ただし、分散型作業モデルを使用することで、より生産性の高いチームを構築できます。これは、より幅広い人材プールにアクセスできるためです。

プログラムのサイズが大きくなるにつれて、小さな変更を加えるためにすべてを理解する必要がないように、プログラムをモジュールに分割することが重要です。多くの場合、これらのモジュールは異なるチームによって提供され、動的に組み合わせることができます。このリファクタリングエッセイでは、プレゼンテーション-ドメイン-データレイヤリングを使用して小さなプログラムを分割します。次に、これらのモジュール間の依存関係をリファクタリングして、サービスロケーターパターンと依存性注入パターンを導入します。これらは異なる言語に適用されますが、見た目が異なるため、JavaとクラスレスJavaScriptスタイルの両方でこれらのリファクタリングを示します。

必須インターフェースとは、相互作用のクライアントによって定義されるインターフェースであり、サプライヤーコンポーネントがその相互作用で使用できるようにするために何を行う必要があるかを指定します。

ソフトウェア開発を、コードを苦労して作成することから、コンポーネントの簡単な組み立てによって強力なシステムを構築することへと変更するという概念は、私がこの職業に就いて以来の目標でした。多くのテクノロジーが産業 재사용のニンジンをつるしてきましたが、それは時々垣間見られるものの、実際には達成されることはありません。

情報量の多いプログラムをモジュール化する最も一般的な方法の1つは、プレゼンテーション（UI）、ドメインロジック（ビジネスロジックとも呼ばれます）、およびデータアクセスの3つの広範なレイヤーに分割することです。そのため、Webアプリケーションは、HTTPリクエストの処理とHTMLのレンダリングについて知っているWebレイヤー、検証と計算を含むビジネスロジックレイヤー、およびデータベースまたはリモートサービスで永続データを管理する方法を分類するデータアクセスレイヤーに分割されることがよくあります。

アンドリュー・ケーニッヒは、JOOPの記事で「アンチパターン」という用語を初めて造語しましたが、残念ながらインターネットでは入手できません。重要なアイデア（私が覚えている限り）は、アンチパターンは、始めるときは良いアイデアのように思えるが、トラブルに巻き込まれるということでした。それ以来、この用語は単に悪いアイデアを示すために使用されることがよくありますが、元の焦点の方が有用だと思います。

アライメントマップは、進行中の作業とビジネス成果の整合性を視覚化するのに役立つ、組織の情報ラジエーターです。作業は、通常の機能追加、または再構築、技術的負債の返済、ビルドおよびデプロイパイプラインの改善などの技術的な作業である可能性があります。チームメンバーは、アライメントマップを使用して、日々の作業がどのビジネス成果を改善することを目的としているかを理解します。ビジネススポンサーとITスポンサーは、それらを使用して、進行中の作業が彼らが気にかけているビジネス成果にどのように関連しているかを理解します。

ループはコレクションを処理する古典的な方法ですが、プログラミング言語でファーストクラス関数が採用されるにつれて、コレクションパイプラインは魅力的な代替手段となっています。この記事では、一連の小さな例を使用して、ループをコレクションパイプラインにリファクタリングする方法を検討します。

アジャイルソフトウェア開発は、要件分析、テスト、開発の間のサイロの一部を打破しました。展開、運用、および保守は、ソフトウェア開発プロセスの残りの部分から同様に分離されている他のアクティビティです。DevOpsムーブメントは、これらのサイロを取り除き、開発と運用のコラボレーションを促進することを目的としています。

多くの開発チームは、マイクロサービスアーキテクチャスタイルがモノリシックアーキテクチャよりも優れたアプローチであることを発見しました。しかし、他のチームは、それらが生産性を低下させる負担であることを発見しました。どのアーキテクチャスタイルと同様に、マイクロサービスにはコストとメリットがあります。賢明な選択をするには、これらを理解し、特定のコンテキストに適用する必要があります。

コレクションパイプラインとは、コレクションを入力として1つの操作の出力として取得し、次の操作にフィードすることにより構成される一連の操作として計算を編成するプログラミングパターンです。（一般的な操作は、フィルター、マップ、および削減です。）このパターンは関数型プログラミングでは一般的であり、ラムダを持つオブジェクト指向言語でも一般的です。この記事では、パイプラインを形成する方法のいくつかの例を使用してパターンを説明します。これは、パターンに慣れていない人にパターンを紹介するためと、人々がコアコンセプトをより簡単に理解できるようにして、ある言語から別の言語にアイデアをより簡単に取り入れることができるようにするためです。

ドクター・フーは長期にわたるテレビシリーズですが、楽しむために多くの時間を費やす必要はありません。優れたスタンドアロンエピソードを簡単に選び出すことができます。

Torの仕組みと使用方法の概要です。Torブラウザバンドル、Hidden Services、Tailsについても説明し、Torにまつわる論争についても触れます。

ここ数ヶ月、成功するマイクロサービスアーキテクチャを実現する唯一の方法は、まずモノリスから始めることだという話を繰り返し聞いてきました。Simon Brownの言葉を言い換えれば、適切に構造化されたモノリスを構築できないのであれば、適切に構造化されたマイクロサービスのセットを構築できるとどうして思えるのでしょうか？ この議論の最も最近の - そして、いつものように非常に説得力のある - 説明は、まさにこのサイトでMartin Fowlerによって行われました。初期の草稿にコメントする機会があったので、このことについて考える時間がありました。そして、私は考えました。というのも、私は普段彼に同意することが多く、私の意見を共有する他の人たちも彼に同意しているように見えたからです。

私は、モノリスから始めることは通常、まさに間違ったことだと確信しています。

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

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

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

YAGNIは元々「You Aren't Gonna Need It（必要なものは作らない）」の頭文字をとったものです。エクストリームプログラミングのマントラであり、アジャイルソフトウェアチームで一般的に使用されています。将来ソフトウェアが必要になると推測される機能は、「必要ないから」今は構築すべきではないという考え方です。

マイクロサービスアーキテクチャスタイルは、昨年最も話題になったトピックです。最近のO'Reillyソフトウェアアーキテクチャカンファレンスでは、すべてのセッションでマイクロサービスについて語られているようでした。皆の「誇大広告検知器」が作動して点滅するほどでした。この結果、チームはマイクロサービスを導入することに熱心になりすぎて、マイクロサービス自体が複雑さを招くことを認識していないことがわかりました。これは、プロジェクトのコストとリスクにプレミアムを追加するものであり、多くの場合、プロジェクトを深刻な問題に陥れます。

Kent Beckは、1990年代後半にエクストリームプログラミングを開発していた際に、シンプルデザインの4つのルールを考案しました。私はそれらをこのように表現します。

外部サービスを扱うコードを書くときは、そのアクセスコードを別のオブジェクトに分離すると便利です。ここでは、凝集したコードをこの分離の共通パターンにリファクタリングする方法を示します。

データレイクとは、ビッグデータの世界におけるデータ分析パイプラインの重要なコンポーネントを説明するために、この10年間に出現した用語です。組織内の誰もが分析する必要があるかもしれないすべての生データを単一のストアに格納するという考え方です。一般的には、Hadoopを使用してレイク内のデータを処理しますが、この概念はHadoopだけにとどまりません。

martinfowler.comサイトの運営は、Thoughtworksでの私の仕事の大きな部分を占めています。従来、私たちのメインサイトよりも多くのトラフィックがありましたが、幸いなことに、メインサイトの改善に伴い、それも変わりつつあります。私のサイトは、私たちがPillar 2の活動の一環として業界に影響を与えるための手段です。

新しいアーキテクチャ用語と同様に、マイクロサービスの適切な定義を得ることは困難です。そのため、この講演では、関心を高めるのに役立ったJamesと私の記事に基づいて、その問題に取り組むことから始めます。次に、マイクロサービスとSOAを比較し、アーキテクチャをよりモノリシックなアプローチと比較し、マイクロサービスアプリケーションをデプロイする前に正しく理解しておくべき重要な点の概要を説明します。

私は、人々の集団の多様性を意図的に高めることについての議論によく参加しています。ソフトウェアで最も一般的なケースは、女性の割合を増やすことです。2つの例は、採用とカンファレンスの講演者リストで、女性の割合を通常のレベルよりも高くしようと議論している場合です。多様性の向上を推進することに対する一般的な反論は、基準が低下し、多様だが凡庸な集団が出現するというものです。

変更を容易にするために最初にコードをリファクタリングすることで、変更を容易にすることができる方法の簡単な例です。