ドメイン駆動設計(DDD/Domain-Driven Design)とオニオンアーキテクチャを数年前から使い始めたWade Waldron氏は，このコンビネーションによってコード品質が劇的に向上したと考えている。中堅ソフトウェア技術者である氏が最初に始めたのはDDDだったが，オニオンアーキテクチャを学んだ途端，コードがもっと読みやすく，理解しやすく，はるかにメンテナンスしやすいものになることに気付いたのだ。
オニオンアーキテクチャはしばしばポートアンドアダプタ，あるいはヘキサゴナルアーキテクチャとも呼ばれる。しかし氏は，これらはオニオンアーキテクチャのスーパーセットであるという考えだ。
コアはドメインや技術に依存しないビルディングブロックで，リストやケースクラス，アクションといった汎用ビルドブロックを含んでいる。技術的な概念，例えばRESTやデータベースといったものが含まれることは決してない。
ドメインとは，すべてのビジネスロジックが，そのドメイン用のユビキタスな言語を使って命名されたクラスやメソッドとして存在する場所である。すべてのビジネスロジックをドメイン内に配置して，APIを介してドメインをコントロールするようにすれば，ビジネスロジックを損なうことなくすべての技術的事項を外部に取り出して，アプリケーションをポータブルにすることが可能になる。
APIはドメインの用語とオブジェクトを使用して，ドメインへのエントリポイントの役割をする。氏は，開発者が公開されたオブジェクトを使って基盤となるドメインにアクセスし，そのドメインを操作するような事態を回避するために，APIでは不変のオブジェクトのみを公開するべきである，と指摘する。APIは，氏がコードの記述を始める部分だ。メソッドのスケルトンと高レベルの機能テストをまず作成し，テストがパスするようにロジックを加えていくことで，ドメインの実装を進めていく。
インフラストラクチャは最外層にあり，データベースやユーザインターフェース，外部サービスなど，さまざまなテクノロジ用のアダプタを含んでいる。すべての内部層にアクセス可能だが，インフラストラクチャを実装するドメインインターフェースを例外として，オペレーションの大部分はAPIを介さなければならない。
重要な概念のひとつは依存性である。外部層から内部層を見ることはできるが，内部層は外部層に関する情報を一切保持しない。
設計を検証するひとつの方法は，新しいデータベースやユーザインターフェースが要求された場合にどうなるかなど，さまざまなシナリオをテストすることだ。DDDとオニオンアーキテクチャの原則に忠実に従っていれば，このような変更にも適応できるはずだ，と氏は考えている。
Alistair Cockburn氏は2005年，従来の階層化やカップリング，絡み合いなどの問題に対するソリューションとしてヘキサゴナルアーキテクチャを提案した。
Russ Miles氏は昨年，このヘキサゴナルアーキテクチャに基づいたLife Preserverのアイデアをプレゼンテーションしている。
３つめの変異型である，Robert C.Martin氏のクリーンアーキテクチャについては，昨年インタビューをしている。