マイクロサービスアーキテクチャパターンとは、単一のアプリケーションを、それぞれが独自のプロセスで実行され、軽量なメカニズム（多くの場合、HTTPリソースAPI）で通信する小さなサービスのスイートとして開発するアプローチです。これらのサービスはビジネス機能を中心に構築され、完全に自動化されたデプロイメント機構によって独立してデプロイ可能です。これらのサービスの集中管理は最小限であり、異なるプログラミング言語で記述され、異なるデータストレージテクノロジーを使用する場合があります。その利点により、ここ数年で非常に流行していますが、分散化の増加、整合性弱体化のコストがかかり、運用管理の成熟度が必要です。

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

優れたフロントエンド開発は難しいものです。多くのチームが大規模で複雑な製品を同時に開発できるようにフロントエンド開発をスケーリングすることはさらに困難です。この記事では、フロントエンドのモノリスを小さく管理しやすい多くの部分に分割するという最近の傾向と、このアーキテクチャがフロントエンドコードに取り組むチームの有効性と効率をどのように向上させることができるかについて説明します。さまざまな利点とコストについて説明するだけでなく、利用可能な実装オプションのいくつかについても説明し、この手法を示す完全なサンプルアプリケーションを詳しく説明します。

確立されたUIパターンは、UI設計における複雑な問題を解決する上で実績のある効果があるにもかかわらず、フロントエンド開発の世界ではあまり活用されていません。この記事では、確立されたUI構築パターンをReactの世界に適用することを、リファクタリングジャーニーのコード例とともに探求し、その利点を紹介しています。Reactアプリケーションの応答性と将来の変更を改善するために、レイヤーアーキテクチャがどのように役立つかを重点的に説明します。

分散システムは、プログラムに特別な課題をもたらします。多くの場合、複数のデータコピーが必要になり、それらを同期させる必要があります。しかし、処理ノードが確実に動作すると信頼することはできず、ネットワークの遅延によって簡単に不整合が発生する可能性があります。それにもかかわらず、多くの組織は、データストレージ、メッセージング、システム管理、および計算機能を処理する、コアとなる分散ソフトウェアに依存しています。これらのシステムは、同様のソリューションで解決する共通の問題に直面しています。2020年、Unmesh Joshiはこれらのソリューションをパターンとして収集し始め、開発を進めながらこのサイトに公開しました。2023年には、これらが「分散システムのパターン」という書籍で出版されました。このページには、各パターンの簡単な概要と、oreilly.comのオンライン電子書籍出版物の関連章へのディープリンクが掲載されています。

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

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

ソフトウェアシステムのオブザーバビリティは常に重要であり、このクラウドとマイクロサービスの時代においてさらに重要になっています。ただし、システムに追加するオブザーバビリティは、どちらかといえば低レベルで技術的な性質のものである傾向があり、多くの場合、さまざまなロギング、インストルメンテーション、および分析フレームワークへの粗雑で冗長な呼び出しでコードベースを散らかす必要があるようです。この記事では、この混乱を一掃し、ビジネスに関連するオブザーバビリティをクリーンでテスト可能な方法で追加できるパターンについて説明します。

Ryan Lockard（Agile Uprising）は、アジャイルプロジェクトのアーキテクチャに関するポッドキャストの会話にRebecca Wirfs-Brockを招待しました。RebeccaはResponsibility-Driven Designを開発しましたが、これは私がキャリアをスタートさせた頃に大きな影響を与えました。私たちは、アーキテクチャの定義方法、アーキテクチャに対するテストの影響、ドメインモデルの役割、どのようなドキュメントを準備するか、そしてどの程度のアーキテクチャを事前に実行する必要があるかについて話し合いました。

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

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

外部サービスを扱うコードを記述する場合、そのアクセスコードを別々のオブジェクトに分離することが重要だと考えています。ここでは、凝集したコードをこの分離の共通パターンにリファクタリングする方法を示します。

私と私の同僚であるBadriとの間で行われた、ヘキサゴナルアーキテクチャとそのRailsアプリケーションでの役割についての会話のビデオをいくつか紹介します。最初のビデオでは、ヘキサゴナルアーキテクチャの意味と、永続化フレームワークのアクティブレコードパターンとデータマッパーパターンの選択について説明します。2つ目では、Railsがアプリケーションで果たすべきアーキテクチャ上の役割について、より広く説明します。Railsをプラットフォームと見なすべきか、コンポーネントのスイートと見なすべきか。

私たちは、多くの場合、一般的なコンテンツ管理システム (CMS) を使用して、豊富なコンテンツを持つ多くの Web サイトを構築しています。最近のプロジェクトでは、グローバルメーカーのマーケティング Web サイトを担当しましたが、可用性とトラフィックのニーズが高い、複雑なインタラクティブコンテンツが求められました。これに対応するために、編集と公開を分離するパターンを適用し、コンテンツの作成と配信のために 2 つの異なるソフトウェアスタックを構築しました。このデッキでは、このアーキテクチャの概要と、スタック間の統合、ライブサイトの安全なプレビューの提供、システムの進化とスケーリングへの対応といった課題に対する私たちのアプローチをご覧いただけます。

依存性逆転の原則 (DIP) は 90 年代初頭から存在していますが、問題解決の最中には忘れがちです。いくつかの定義の後、私が実際にプロジェクトで使用した DIP のアプリケーションをいくつか紹介します。これにより、独自の結論を導き出すための例が得られます。

LMAX は、新しいリテール金融取引プラットフォームです。そのため、低レイテンシで多くの取引を処理する必要があります。このシステムは JVM プラットフォーム上に構築されており、単一スレッドで毎秒 600 万件の注文を処理できるビジネスロジックプロセッサを中心にしています。ビジネスロジックプロセッサは、イベントソーシングを使用して完全にメモリ内で実行されます。ビジネスロジックプロセッサは、Disruptor によって囲まれています。Disruptor は、ロックを必要とせずに動作するキューのネットワークを実装する並行性コンポーネントです。設計プロセス中に、チームは、キューを使用する高性能並行性モデルの最近の動向は、最新の CPU 設計と根本的に矛盾しているという結論に達しました。

エンタープライズソフトウェア開発のためのパターンをカタログ化するさまざまな取り組みの個人的な調査。

Ruby Rogues は、Ruby プログラミングコミュニティのトピックについて定期的なパネルが議論する人気のポッドキャストです。彼らは定期的なブッククラブを持っており、最近 EAA の P を特集書籍として選びました。その結果、彼らは私に番組のゲストとして出演し、この本とそれが記述するパターン、特にこれらのパターンと Rails フレームワークの興味深い関係について議論するように依頼しました。

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

従来のフレームワークベースの依存性注入に対する不満に基づき、私は部分適用を利用してモジュールにコンテキストを注入する合成戦略を採用しました。テスト駆動開発を設計プロセスとして組み合わせ、クラスよりも関数に焦点を当てると、モジュールを明確、クリーン、そしてほとんど意図しない結合から解放することができます。

Software Development 誌は、私の著書「エンタープライズアプリケーションアーキテクチャのパターン」の第 7 章 (分散戦略) を記事として採用しました。そのトーンと分散オブジェクト設計の第一法則が含まれていることが気に入ったのだと思います。

システムがどのように動作し、ピアとどのように連携するかについて、イベントをどのように中心に据えることができるかを探るパターンの物語。イベントを表現する方法、システム間の統合にイベントを使用する方法、システムのアーキテクチャでイベントソーシングを使用する方法をまとめています。

GUI アーキテクチャがどのように進化してきたかについての歴史的概要。特に、Model-View-Controller が長年にわたってさまざまなグループによってどのように見られてきたかに注目しています。歴史的な観点から、私のプレゼンテーションパターンと結びついています。

ユーザーインターフェースにおけるパターンの概要。ドメインロジックをプレゼンテーションから分離する方法と理由、およびデータレイヤーを分離および同期する方法について説明します。

最近、私の同僚である Neal Ford、Rebecca Parsons、Pat Kua が「進化型アーキテクチャの構築」という本を書きました。彼らから序文を書いてほしいと頼まれ、光栄に思いました。

コンウェイの法則 (1968 年に Melvin Conway によって定式化された) は、システムの設計はその設計者のコミュニケーションパターンによって制約されると述べています。Birgitta、Mike、James、そして私はこの原則の意味と、私たちのキャリアの中でどのようにそれが現れてきたかについて議論します。マイクロサービスの概念への影響、ビジネス機能との整合性の重要性、逆コンウェイ操作の役割について話します。

これはかなり長い間存在しているアンチパターンの 1 つですが、現時点では特に流行しているようです。Eric Evans とこのことについて話していましたが、私たち2人とも、それらがより一般的になっていることに気づきました。適切な ドメインモデル の強力な支持者として、これは良いことではありません。

ソフトウェア開発の未解決の問題の 1 つは、ソフトウェアの境界を決定することです。(ブラウザはオペレーティングシステムの一部ですか?) サービス指向アーキテクチャの多くの支持者は、アプリケーションはなくなると考えています。そのため、将来のエンタープライズソフトウェア開発はサービスをまとめて組み立てます。

アプリケーションがなくなることはないと思います。それは、アプリケーションの境界線を引くのが難しいのと同じ理由からです。本質的に、アプリケーションは社会的な構築物です

CQRS は、コマンドクエリ責務分離の略です。これは、私が Greg Young から最初に聞いたパターンです。その中心にあるのは、情報を更新するために使用するモデルとは異なるモデルを使用して情報を表示できるという考え方です。状況によっては、この分離は有益な場合がありますが、ほとんどのシステムでは CQRS はリスクの高い複雑さを追加することに注意してください。

ソフトウェアシステムが、異なるプロセスで実行されているソフトウェア、おそらくネットワークを介した異なるマシンで実行されているソフトウェアにリモートコールを行うのは一般的です。メモリ内呼び出しとリモート呼び出しの大きな違いの 1 つは、リモート呼び出しが失敗したり、タイムアウト制限に達するまで応答なしでハングしたりする可能性があることです。応答のないサプライヤに多くの呼び出し元がいる場合、さらに悪いことに、重要なリソースが不足し、複数のシステムにわたるカスケード障害につながる可能性があります。彼の優れた著書 Release It で、Michael Nygard は、この種の壊滅的なカスケードを防ぐためにサーキットブレーカーパターンを普及させました。

サーキットブレーカーの背後にある基本的な考え方は非常にシンプルです。保護された関数呼び出しをサーキットブレーカーオブジェクトでラップし、障害を監視します。障害が特定のしきい値に達すると、サーキットブレーカーがトリップし、サーキットブレーカーへのそれ以降のすべての呼び出しは、保護された呼び出しがまったく行われずにエラーで返されます。通常、サーキットブレーカーがトリップした場合、何らかのモニターアラートも必要になります。

ここ数年、「クラウド」という言葉は非常に誇大宣伝されてきました。誇大宣伝された言葉の特徴の1つは、定義がほとんどないか、まったくないことです（そう、NoSQLの定義、あなたのことですよ）。

ところが、クラウドコンピューティングの優れた定義が、他ならぬNISTから提供されています。驚くほど短く分かりやすい標準文書で入手できます（いいえ、冗談ではありません）。

私は執筆活動において、検証に関する資料をたくさん書くつもりでいました。検証は混乱を招きやすい分野であり、うまくいくいくつかのテクニックについてしっかりと説明することが重要です。しかし、人生には書くべきことがたくさんあり、時間の方が足りません。

私が尊敬するソフトウェアアーキテクチャの実務家は、ほぼ全員が、この分野における一般的な法則には非常に懐疑的です。優れたソフトウェアアーキテクチャは非常にコンテキストに依存しており、トレードオフの分析結果は、幅広い環境で異なります。しかし、彼らが全員同意する点が1つあります。それは、コンウェイの法則の重要性と威力です。私がこれまで見てきたすべてのシステムに影響を与えるほど重要であり、それと戦うと敗北するほど強力です。

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

QConサンフランシスコで私が参加した興味深い講演の1つは、Greg Young氏が、最近彼が使用した特定のアーキテクチャについて行った講演です。Greg氏はドメイン駆動設計の大ファンであり、このケースでは、大量のトランザクションを処理し、多くのユーザーにデータを提供する必要があるシステムで使用される必要があります。彼の設計には、イベントソーシングの使用など、興味深い点がいくつかありましたが、この記事では、私が先行読み込みによる派生と呼ぶ1つの側面に焦点を当てたいと思います。

ここ1、2年、Thoughtworksのプロジェクトチームとの会話の中で、コンテンツ管理システム（CMS）の影響力の増大が定期的なテーマとなっています。CMSは通常、役に立つとは見なされていません。実際、CMSが心配になるほど侵入的なツールになりつつあるという明確な兆候があります。つまり、CMSは本来の目的以上のことに使用され、全体的な開発を阻害しています。

他の煩わしさの中でも、よくある欠点は、各記事のコピーを1つだけ保持することです。この単一のコピーは、コンテンツの作成中に編集され、読者に公開されます（通常、状態変更フラグによって）。

今世紀初頭、私は著書『エンタープライズアプリケーションアーキテクチャパターン』に取り組んでいました。この本を執筆する際に抱えていた問題の1つは、タイトルをどうするか、あるいは私が書いているソフトウェアシステムを何と呼ぶかでした。私は、自分のソフトウェア開発経験が常に特定の形式のソフトウェア、つまり医療記録、外国為替取引、給与計算、リース会計などに焦点を当ててきたことを常に意識していました。これらは、プリンター、ゲーム、飛行制御ソフトウェア、電話交換機などに組み込まれたソフトウェアとは大きく異なります。私は、これらの種類のシステムを説明するための名前が必要で、「エンタープライズアプリケーション」という用語を選びました。

最近、『エンタープライズアプリケーションアーキテクチャパターン』について、エンタープライズアーキテクチャに関する記述がないという理由で、Amazonでいくつか悪いレビューを受けました。もちろん、それには正当な理由があります。この本はエンタープライズ*アプリケーション*アーキテクチャ、つまりエンタープライズアプリケーションの設計方法について書かれています。エンタープライズアーキテクチャは別のトピックであり、企業内の複数のアプリケーションをどのように一貫性のある全体に編成するかということです。

これは、私が何度か出会ったアプリケーションのスタイルです。このアプリケーションは、主に、ユーザーに何かの状態に関するリアルタイム情報を提供するレポートアプリケーションです。これはアクティブなアプリケーションであり、ユーザーは見ているものの種類を詳細に制御し、特定の領域をドリルダウンしたり、表示を操作したりできます。ただし、少なくとも主に読み取り専用のアプリケーションです。

ソフトウェアシステムについての理解を深める上での問題の1つは、十分な例を見ることができないことです。多くの専門分野では、人々はすでに行われたことを見ることで学びます。例は、インスピレーション、優れたアイデアの源、そして困難の警告として役立ちます。長い間、ソフトウェアについてこのように学ぶことはずっと難しいことでした。

分散オブジェクト設計の私の第一法則：オブジェクトを分散しない（『エンタープライズアプリケーションアーキテクチャパターン』より）。

アプリケーションプログラミング言語とリレーショナルデータベース間で通信を行うほとんどのライブラリを見ると、データベースの文字列型（charまたはvarchar）がプログラミング言語の文字列型にマッピングされていることがわかります。シンプルで明白ですが、おそらく間違っています。

私はプログラミングをしていて、現在入力している場所の上に空行を追加したかったのです。私が使用していたエディターにはこの機能が組み込まれておらず、ついにその欲求が限界に達しました. 私はGoogleで簡単な検索を行い、数行のコードを見つけ、それをスタートアップファイルに貼り付けて実行しました。すると、1つのキーストロークで上の空行を作成できるようになりました。わずか数分で完了し、プラグインをインストールしたり、エディターを再起動したりする必要はありませんでした。これはemacsユーザーにとっては当たり前のことです。

制御の反転は、フレームワークを拡張する際に遭遇する一般的な現象です。実際、これはフレームワークを定義づける特性と見なされることがよくあります。

ソフトウェア開発チームは、できるだけ頻繁に作業を統合すれば、作業がはるかに楽になることに気づいています。また、本番環境に頻繁にリリースすることの価値にも気づいています。しかし、チームは未完成の機能をユーザーに公開したくありません。この緊張に対処するための便利なテクニックは、すべてのバックエンドコードを構築して統合しますが、ユーザーインターフェースは構築しないことです。この機能は統合してテストできますが、UIは最後まできーストーンのように機能を完成させるために追加されるまで保留され、ユーザーに公開されます。

ここ数日、Jimmy Nilsson氏が主催するノルウェーのエンタープライズソフトウェアに関するワークショップに参加していました。ワークショップでは、設計原則を考案して投票するセッションがありました。

私の仲間のThoughtブロガーに注目していたなら、私のファウルボットの1つがヒューズを飛ばしたようです。オーストラリアの太陽は明らかにこれらのスウェーデンモデルを焦がします。

Jonはデータ転送オブジェクトに悩まされていますが、DTOが悪いことではありません。他のパターンと同様に、特定のコンテキストで役立ちます。パターンには常に2つの部分があります。方法とタイミングです。実装方法を知る必要があるだけでなく、いつ使用するか、いつ放置するかを知る必要があります。

最近のクライアントエンゲージメントでは、サーバーレスアーキテクチャが最適であると予測しました。しかし、サーバーレスアーキテクチャを採用するというアイデアは、ベンダーロックインの懸念から、クライアントにはうまく受け入れられませんでした。小売業者にとって、AWSにとどまると、別の小売業であるAmazonに競争上の優位性が与えられる可能性があるため、興味深い時期でした。競合他社をサポートしないという考え方を踏まえ、クライアントは、私たちが選択したソリューションが他のクラウドベンダーに移植可能であることを確認することに関心を持っていました.

人々がエンタープライズアプリケーションを開始するとき、最初の質問の1つは「データベースとどのように通信するか」です。最近では、彼らは少し異なる質問をするかもしれません。「どのような種類のデータベースを使用する必要がありますか？リレーショナルデータベースですか？それともこれらのNoSQLデータベースの1つですか？」しかし、考慮すべき別の質問があります。「データベースをまったく使用する必要がありますか？」

2か月前、ロンドンで開催されたQConカンファレンスに参加したとき、すべての講演にオブジェクト/リレーショナルマッピング（ORM）ツールに関する皮肉な発言が含まれているようでした。45分ごとに少なくとも1回はORMを軽蔑するようにとの指示が、講演者に送信されたカンファレンスメールに書かれていたのでしょう。もっと注意深く読むべきだったと思います。しかし、お分かりのように、私はこのORMへの嫌悪に少し反論したいと思います。なぜなら、その多くは不当なものだと思うからです。

2006年、私の同僚であるNeal Fordは、多言語プログラミングという用語を作り出しました。これは、さまざまな言語がさまざまな問題の解決に適しているという事実を利用するために、アプリケーションはさまざまな言語の組み合わせで記述されるべきだという考えを表現したものです。複雑なアプリケーションはさまざまな種類の問題を組み合わせているため、すべての側面を1つの言語に合わせようとするよりも、ジョブに適切な言語を選択する方が生産性が高くなる場合があります。

ここ数年、新しい言語、特に関数型言語への関心が爆発的に高まっており、私はしばしばClojure、Scala、Erlangなどに時間を費やしたいという誘惑に駆られます。しかし、私の時間は限られており、より重要で大きな変化であるデータベースの融解（Database Thaw）に、より高い優先順位を与えています。クライアントや他の連絡先から最初の兆候が現れ始めており、その見通しは魅力的です。新しい戦略的なエンタープライズアプリケーションを開始する場合、永続化がリレーショナルであると想定するべきではないと自信を持って言えます。リレーショナルオプションが適切な場合もありますが、他の選択肢を真剣に検討する必要があります。

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

私が発見し、従ってきた最も有用な設計原則の1つは、プログラムのプレゼンテーションの側面（ユーザーインターフェース）と残りの機能を適切に分離することです。私がこれをやってきた何年もの間、多くの利点を見てきました。

公開インターフェースとは、定義されているコードベースの外部で使用されるクラスインターフェースを指すために私が使用した用語です（最初にリファクタリングで使用）。そのため、Javaのpublicよりもさらに、C＃の非内部publicよりもさらに多くの意味を持ちます。IEEE Softwareのコラムでは、公開と公開の区別は、実際には公開と非公開の区別よりも重要であると主張しました。

ほとんどのエンタープライズアプリケーションは、永続データをデータベースに格納します。このデータベースは、アプリケーションの状態の運用上の更新と、意思決定支援と分析に使用されるさまざまなレポートをサポートします。ただし、運用上のニーズとレポートのニーズは、スキーマの要件とデータアクセス パターンが異なり、多くの場合まったく異なります。このような場合は、運用データのコピーを取得するものの異なるスキーマで表現する、レポーティングデータベースにレポートのニーズを分離することをお勧めします。

Thoughtworksの同僚と話をしていると、唯一の優れたエンタープライズサービスバス（ESB）は、機能していないESBであるという印象をすぐに受けます。ジム・ウェバーはそれらを誤ったスパゲッティボックスと呼んでいます。そのため、それらを必要としないシステムからそれらを排除しようとする試みの話を聞くことは珍しくありません。

多くのプログラムは、作成と維持に費用がかかるリソースを利用する必要があります。これらの例としては、データベース接続とスレッドがあります。リソースプールは、これらのリソースを管理するための優れた方法を提供します。

あなたは会議に座って、あなたのチームが過去数年間取り組んできたコードについて考えています。あなたは今できる最良のことは、そのコードをすべて捨てて、まったく新しいアーキテクチャで再構築することだと判断しました。それは、その運命にあるコード、それに費やした時間、ずっと前に下した決定について、どのように感じさせますか？

サーバーレスアーキテクチャは、アプリケーション開発が通常のサーバープロセスを使用しないインターネットベースのシステムです。代わりに、サードパーティサービス、クライアントサイドロジック、およびサービスホスト型リモートプロシージャコール（FaaS）の組み合わせにのみ依存します。

ソフトウェア開発を、コードを苦労して作成することから、コンポーネントを単純にアセンブリすることで強力なシステムを構築することへと変えるという考えは、私がこの職業に就いて以来の目標でした。それは時々垣間見える目標ですが、多くのテクノロジーが産業的再利用のニンジンをぶら下げてきましたが、実際には達成されていません。

開発チームが自分の仕事について話しているのを聞いていると、1つの共通のテーマは、静的に保持されているものに対する嫌悪感です。通常、静的イニシャライザを使用して静的変数に保持されている共通サービスまたはコンポーネントが表示されます。静的（ほとんどの言語で）の大きな問題の1つは、ポリモーフィズムを使用してある実装を別のものに置き換えることができないことです。私たちはテストの大ファンであるため、これは私たちにとって大きな問題です。適切にテストするには、サービスをサービスタブに置き換えることができることが重要です。

シンディと私はオーストラリアに行ったとき、クイーンズランド州の海岸にある熱帯雨林でしばらく過ごしました。この地域の自然の驚異の1つは、巨大な絞め殺しのイチジクです。彼らは木の高い枝に種をまき、徐々に木を下りて土に根を下ろします。何年にもわたって、彼らは幻想的で美しい形に成長し、その間、彼らの宿主であった木を絞め殺して殺します。ソフトウェアにおける絞め殺しのイチジクアプリケーションは同じパターンに従います。

これは悲しいほど一般的なアーキテクチャスタイルだと思います。あなたの会社は非常に高価なインフラストラクチャソフトウェアを購入します。その後、プロジェクトに適していなくても、余分な労力がかかっても、プロジェクトでそれを使用する必要があると言われます。それだけの費用を支払った後、それを無駄にしたくないでしょう？

モバイルアプリケーションは、過去数年間、ソフトウェア開発のホットアイテムでした。多くのソフトウェア配信会社と同様に、Thoughtworksはクライアントからモバイルアプリケーションの構築を依頼されることがよくあります。しかし、ほとんどの場合、企業が私たち（または誰かに）モバイルアプリケーションの構築を依頼するとき、彼らは間違った道を進んでいます。ほとんどの場合、ユーザーにモバイルデバイスと対話させたい場合でも、**モバイルアプリケーションの構築について考えるべきではない**と私は主張します。代わりに、モバイル、デスクトップ、タブレットなど、ユーザーが使用する可能性のあるあらゆるデバイスに表示される単一のアプリケーションの構築について考える必要があります。

数年前、私はeBayで仕事をしていた私の2人の友人と話していました。大量のサイトで使用されている手法について聞くのは常に興味深いことですが、おそらく最も興味深い情報の1つは、eBayがほとんどデータベーストランザクションを使用しないことです。

2006年の夏、私はUIパターンに多くの時間を費やしました。それ以来、私の主な執筆の焦点はドメイン特化言語に移行したため（それほど目立たないものの）、それらは非常に凍結されています。このページでは、私が気に入った、その作業に関連する著作へのリンクをメモしておきます。

ソフトウェアシステムの一般的な機能は、ユーザーがデータ構造に独自のフィールドを定義できるようにすることです。アドレス帳を考えてみましょう。追加したいものがたくさんあります。毎日新しいソーシャルネットワークが登場するにつれて、ユーザーは連絡先にBunglr IDの新しいフィールドを追加したいと思うかもしれません。