理想を追求していいならこうするという方法

[77web]

どのようにコーディングしましたか？

Controller→UseCase→Service→Model というレイヤーにしています。
Modelは、いつかSymfonyもDoctrineも捨てるかもしれないときにも移植できる部分として作ります。実際に他のパッケージ（社内packagist向けのプライベートパッケージ）として作ることも多いです。
ServiceまではDoctrineを知っても良いことにしています。

このコーディングのポイントを教えてください。

ビジネスロジックをDoctrine, Symfonyと疎結合に書くこと。
※ ただしこのシステムぐらいDB保存以外に何もしないシステムなら疎結合にする必要はないと判断するかも

どのようなことに注意していますか？

ビジネスロジックをDoctrine, Symfonyのクラス（レイヤー）に依存させないこと。

その他、コメントがあれば

現実の業務ではもう少しレイヤー分けを妥協することが多いです。
ModelがDoctrineに依存するのを許したり、UseCase→Service,Service→Serviceの依存時にinterfaceを挟まなかったり。
逆に言えばレイヤー分け以外の部分は基本的に妥協しません。
このクラス分けをビジネス側に許容させるために意識してコーディングスピードを激上げていると言っても過言ではありません。「中身がゴチャゴチャでもいいから動くものを速く作って」とは言わせません。

[77web]

昨日のSymfonyWorldで私と同様のアプローチの方がいて感動しました！
https://slidr.io/derrabus/dependency-injection-demystified

ただしこの方の場合UseCaseレイヤーはないです。