アーキテクチャの目的は意図であるが、私たちはそれをフレームワークや詳細だとしてきた。「ボブおじさん」ことRobert C. Martin氏はロンドンで開かれた今年のDDD Exchange Dayでこのように述べた。
Robert氏は「Growing Object-Oriented Software Guided by Tests」という本で説明されたアーキテクチャモデル（Hexagonalアーキテクチャに似ている）について言及した。その本では、不安定な部分から安定した部分へと、一方向の依存関係を持つ3つのゾーンを持ったアーキテクチャについて説明している。
- ドメインモデル。コアとなるビジネスルール、ビジネスにとって最も安定して重要な部分を持ち、他には依存しない。
- アプリケーションサービス。ドメインモデルを利用し、ドメインモデルに依存したシステムのユースケースを実現する。
- 外部詳細。データベース、ユーザインターフェイス、ネットワークなど、ビジネスモデルにはそれほど関係がない。最も不安定で他の2つに依存する部分。
彼が重要だと考えていること、アーキテクチャの目的は意図、すなわちアプリケーションがやることだということは、このモデルだとうまく説明できないと彼は述べた。私たちは詳細やフレームワークにフォーカスしすぎており、それらをシステムの中心にしてしまっていると彼は考えている。
この欠点を解決するため、Robert氏はIvar Jacobsonによる1992年の本、「Object-Oriented Software Engineering, A Use Case Driven Approach」に立ち戻った。その本でIvar氏は、詳細ではなく小さなユースケースに基づいたアプリケーションアーキテクチャの仕組みを定義している。
Ivar氏はアーキテクチャモデルに合った3種類のオブジェクトを紹介しており、Robert氏はこれらを次のように説明した。
- インタラクタ。ユースケースを理解し、アプリケーション固有のビジネスルールを持つ。
- エンティティ。ビジネスルールを持ち、インタラクタによって利用される。
- バウンダリオブジェクト。外部世界とインタラクタとの間でデータを転送する。
Robert氏が言うには、このモデルの大きなメリットは、テスト可能なモデルだということだ。バウンダリオブジェクトを通してデータ構造を送受信することによって、インフラストラクチャに依存することなくテストが可能になる。
そして、Robert氏はさきほど説明したアーキテクチャの一種である、Cleanアーキテクチャモデルに話を移した。3つのモデルすべてで重要なのは、これらのモデルが安定依存の原則（Stable Dependencies Principle）に従っているということだ。「変更するもの、あるいは変更する可能性の高いものに依存してはいけない」。外部にある不安定な部分をより安定した部分、例えばドメインモデルに依存させることで（逆向きではない）、これを実現している。またこれにより、実装は変更しやすくなる。不安定な部分が安定した部分に依存しているためだ。Robert氏の言葉を引用すると、
すぐれたアーキテクチャとは、簡単に変更できる不安定な決定を許すものです。
Robert氏はまたJim Coplien氏とDCIアーキテクチャに言及した。彼はこれをほかのアーキテクチャとよく似ていると考えている。
この数年、Robert氏のこうした考え方に対して、いくつか批判もあがっており、Robert氏もこうした批判に対して回答している。