断り書き:自分たちがやりたいDDDにDoctrineが必ずしも向いていないという判断をしたものです。Doctrineには非常にお世話になっており、批判するものではありません。どのツールにも適材適所があると思います。
機械的なORMでエレガントに表現できないものがあった（ValueObjectなど）
Entityが1テーブルに固く対応していて、さらにその知識がインフラストラクチャレイヤからドメインレイヤに漏れ出していて、密結合が発生していた
Doctrineロックから脱出したい。Domain ServiceはRepositoryに依存しており、RepositoryはDoctrineに依存している。Doctrineが破滅への道を歩めば、アプリの心臓であるDomainも道連れとなる。
ストレージロックを脱出したい。ドメインレイヤがある具体的なRepositoryに依存していると、簡単にストレージを交換することができない。
インフラストラクチャレイヤはドメインレイヤに依存すべきと学んだ（ここが一番おおきな転換点）。普通の伝統的な設計では、下記図のような依存関係を作る。
このままでは、インフラレイヤの呪縛から逃れられない。Implementing Domain-Driven-Design では下記図のように、依存関係を逆転させること、Dependency Inversion Principle*1を実践することを強く提唱している。
Doctrine ORMを使っている限り、ドメインはインフラに依存しつづけるので、Doctrine ORMはやめて、独自でRepositoryを作ることにした。
このアーキテクチャでは、初期工程でストレージについて一切議論しない。ストレージなんてMySQLだろうがMongoDBだろうがなんでもいい、そんつぁもん一番 後に決めればいいねっか！ポッペンディークもLean Software Developmentで「決定を遅らせる」ことはいいことだと言っている。
その代わり、最も重要なドメインを先に設計し、ドメインがインフラに対して必要とするインターフェイスを定義する。最後の工程で、インフラはそのインターフェイスにしたがって、必要なリソースを提供できるストレージを選択する。
*1 Dependency Inversion Principle は、ロバート・C・マーチンが提唱している、セパレートインターフェイス[Fowler, PoEAA]を使った依存関係の逆転を行う指針だ。同氏は他にも同様の指針を、SOLID (SRP, OCP, LSP, ISP, DIP)として定義している。