エンタープライズアーキテクチャグループは、日常の開発から切り離されることがよくあります。これにより、開発作業に関する彼らの知識が古くなり、開発チームが会社全体の幅広い視点を持たなくなる可能性があります。私の同僚（Thoughtworks CTO）であるレベッカは、この状況を頻繁に見てきたため、エンタープライズアーキテクトは開発チームに参加することで、より効果的になれると主張しています。

システムが大幅なコード変更なしに変更できるようにするテーブル駆動型技術。

バリスタは同期処理を行いません - 彼らの理由は、あなたも非同期にする理由になるかもしれません。

明確なコードは良いことですが、テスト容易性のために明確さを犠牲にすべきでしょうか？

ソフトウェアがうまくいかない場合、ジムはこのコラムで、可能な限り早く崩壊すべき理由を説明しています。

誰もが独自の重要な設計ガイドラインのリストを持っています。スコットはインターフェースと、正しく使用するのが簡単で、誤って使用するのが難しいように設計する方法に焦点を当てています。

OOPSLA 2003で、デイブ・トーマス（OTIの創設者）は、モデル駆動アーキテクチャについて思慮深く強力な批判を行いました。このコラムで彼は、普遍的なモデル駆動型アプローチが失敗する可能性が高いと考える理由を説明し、UMLとドメイン固有言語にはまだ価値があることを指摘しています。

リファクタリング、JUnitなどのツール、エクストリームプログラミング（XP）などのアジャイル手法の普及により、新しいスタイルの設計が注目されています。継続的設計とは、リファクタリングを使用してプログラムの設計を継続的に改善するプロセスです。このコラムでは、ジムは、国際化やトランザクションなど、扱いにくいと思われる設計上の問題を含め、継続的設計の経験について議論しています。

特にオブジェクト指向システムでは、カプセル化の一般的な部分として、データ構造を隠すことが挙げられます。しかし、これらのデータの多くをデータアクセスルーチンによって公開することも一般的です。このコラムでは、データアクセスルーチンを作成するためのいくつかのガイドラインを紹介します。ただし、データを隠したままにできる場合は、通常それがより良いことを忘れないでください。

アーキテクチャとは何ですか？そして、アーキテクトとは正確には誰ですか？これらは、誰もが非常に熱くなる質問のようです。そこで、このIEEE Softwareのコラムでは、ラルフ・ジョンソンにアーキテクチャについて説明してもらいます。それは、誰もが同意しない方法で、他のすべての定義と一致する定義です。また、私はアーキテクトの2つの亜種についても話します：Architectus Reloadus と Architectus Oryzus。

ソフトウェアアーキテクチャについて考えるとき、私たちは通常、その技術的なアーキテクチャについて考えます。しかし、もう1つ重要なアーキテクチャがあります。それは、ソフトウェアの顧客とコミュニケーションするために使用するアーキテクチャ、つまりマーケティングアーキテクチャです。この「マーケテクチャ」と「テクテクチャ」の関係を無視すると、開発プロジェクトは多くの問題に陥る可能性があります。

なぜカオス理論は、コンポーネントのアセンブリがそれほど簡単ではない可能性を示唆するのか。

ソフトウェア設計の理解にパターンがもたらすことができる貴重な貢献に関する私のIEEEコラム。

値に新しいユーザー定義型（またはクラス）を作成するタイミングに関するガイドライン。

メタデータベースのアプローチを使用して、退屈なデータ指向タスクの苦痛を取り除くことができます。

ジムとアレクセイは、NUnitの新しいバージョンを開発する上で主導的な役割を果たしました。これにより、新しい.NET言語機能である属性が設計にどのように影響するかについて考察しました。

パフォーマンスの最適化に関する確立された原則の多くがあまり知られていないことに、いつも驚かされます。この記事は、これらをカバーするためのもう1つの試みです。

多くの現代言語では、モジュール内のパブリック機能とプライベート機能が区別されています。あまり区別されていないのは、パブリック機能と公開機能の区別であり、それがより重要な区別である可能性があります。

ソフトウェアで繰り返しを避けるという単純なルールが、いかに優れた設計につながるかは、時々非常に驚くべきことです。

私が最初に学んだ教訓の1つは、常にユーザーインターフェースコードを他のものから分離しておくことでした。これは依然として良いアドバイスであるだけでなく、驚くほど忘れられることが多いです。

このコラムのクレイグの箇所では、オープンクローズド原則と保護されたバリエーションの重要性、およびパーナスの情報隠蔽がカプセル化以上の理由を考察しています。彼はまた、保護されたバリエーションを実装する方法に関するヒントもいくつか提供しています。

結合を視覚化し、削減する方法について考えます。

多くの場合、設計技術はシステムをより柔軟にするために使用されますが、最終的には扱いが難しくなります。理由の1つは、明示性が設計で忘れられがちな特性であるためです。

テスト容易性は非常に重要な美徳であるため、システムのテスト容易性を向上させるためにアーキテクチャ上の決定を下す必要があります。

モジュールプログラミングは、インターフェースへのプログラミングだけでなく、さまざまなモジュールがどの具象モジュールと通信しているかを知らずにモジュールを組み立てることでもあります。

描くモデルの種類は、それらを何に使うかという目的に依存します。ジョンは、概念モデル、仕様モデル、および実装モデルの間の有用な区別を説明しています。