ドメイン駆動設計の著者であるEric Evans氏は、仮に2003年に書かれたこの本の内容はもはや古臭くて妥当しないことも多いと異議を唱えることがあるとしても、そこで提示されているコンセプト群は、14年前よりも今のほうがより妥当で納得感をもって受け入れられる状況になっていると語った。Colorado州DenverのExplore DDDカンファレンスは、Evans氏の基調講演のプレゼンテーションで始まった。これは、北アメリカで行われる、ドメイン駆動設計に注目した初めてのカンファレンスだ。Evans氏は、ソフトウェア開発の歴史的な見取り図に沿って、DDDの主要なコンセプトを振り返った。様々なツールや技術のスコープが拡張されて、そのいくつかは、私たちが過去に持っていたものに比べよりDDDの原則に適合したものへと進化している。「DDDは技術に関するものではないが、決して技術に無関心なものではない」とEvans氏は述べた。

2003年の最先端を振り返って見ると、Java、J2EE、SQLデータベース、オブジェクト-リレーション・マッピングORMがあったが、これ以上の選択肢はあまりなかった。選択肢がないことで、いくつかのツールが、唯一有効なオプションだったために使われることになった。例えば、ORMは私たちがすべてをこれで取り扱うべきだという手法ではないが、10年から15年もの間、続いていると、Evans氏は言った。しかし、どのツール、パターン、アーキテクチャも、ある状況下では正しくなくなるとまで言うつもりはなく、むしろ、Evans氏は、見境なく適用される、たった1つの解決方法しかないことに苛立っていたのだという。また、Evans氏は、DDDが過去14年間以上に渡って進化してきたことを信じていると主張した。したがって、もし私たちが「私が本に14年前に書いたとおりのDDDを行ってきたとしたなら、それは今の状態とは違ってひどく残念な状況になっていたことでしょう。」と明言した。

Evans氏のDDD本の多くのコンセプトは、その当時のツールで実装するのは難しかったけれども、現代のプラットフォームではずっと簡単に行えるようになっている。彼の本で提案した1つのコンセプト、「値オブジェクトを不変にする」ことは、過去には難しくて、ほとんどやる価値がなかったことをEvans氏は認めた。それに比べて、関数型言語は不変をより簡単に実現可能なものにした。同様に、マイクロサービスの考え方が評判になることでコンテキスト境界が大事だよと理解が促進されるようになったし、NoSQLデータベースは、リレーショナルデータベースよりもDDDの集約（Aggregates）をよりよく管理できる。ソフトウェアの核心部分で複雑さの制御に取り組むことに常に注力し、完全にモデルを表現しているソフトウェアを書くことに貢献する、こうした技術的進化を、Evans氏は賞賛した。「技術がこのようにあなたたちをサポートしてくれるなら、よりよいモデルを考え出すことに集中できます。」

ソフトウェアにおいて妥協とトレードオフは避けられないものであり、「すべての大規模システムがうまく設計される訳ではない」ことを、誰もが受け入れるように、とEvans氏は励ましの言葉を述べた。「よい塀がよい隣人を作る」ように、コンテキスト境界がシステムの悪い部分からよい部分を守ってくれる。ということは逆に、すべての開発が、しっかり定義されたコンテキスト境界の中に置かれているわけではないし、すべてのプロジェクトがDDDで実施される訳でもない、ということが必然的に導かれるといえるだろう。開発者はしばしばレガシーシステムに携わることを嘆くが、Evans氏は、レガシーシステムに高い価値を見いだす。それらが企業にとって、お金になるからだ。Evans氏が、「いつの日か、あなたたちのシステムがレガシーシステムになることを望む」ように開発者たちを励ますと、一斉の拍手が沸き起こった。

Evans氏は、また、オープンソースソフトウェアを、特に学習の手段として奨励し、例を読んでSmalltalkを学んだことを紹介した。こうしたオープンソースやSmalltalkのカルチャーは、プレゼンテーションの3分の1は現実世界のケーススタディとDDDを実装した経験を共有することに充てられているイベントExplore DDDの考え方やコラボレーション重視の環境とも適合するものといえる。

Evans氏は、エレガントな設計を支持する方向に世の中の流れが変わってきたことに喜んでいる。Evans氏の本には、システムを拡大できない時にぶつかる問題(それが結果として拡大できないビジネスを生む)の扱い方が書かれていた。自己完結的な要求として、「よりクリーンな設計へのニーズが、よりクリーンな設計を生み出すのです」とEvans氏は言った。