phpTweet最近書いているような実装方法でSymfony4のサンプルコードを書いてみました。polidog/sf4-login-sampleサンプルを作ったきっかけは以下のツイート。Symfonyの認証まわり実装するときにUserエンティティにUserInterfaceをimplementsしなきゃいけないの辛い。2018年7月24日Symfonyとドメイン的なエンティティが分離している状態でなのに、ログイン関連の実装するときはSymfonyのSecurityコンポーネントのUserInterafceが必須になってしまう。これは外部のライブラリに依存してしまっている状態なのでなんとかしたかった。そんな気持ちから「僕の考えた最強のしんふぉー」って感じでサンプルコードを実装してみようという気持ちでサンプルの実装をしてみました。基本的にはsymfonyの標準的な構造になっています。若干違うところは以下の通りです。コアレイヤ的な実装が入っているというところでしょうか。それに合わせてテストも「tests」と「tests_domain」に分かれています。自分の中のsrc_domainでの実装ルール外部ライブラリに依存する場合は、基本的にはこちらからInterfaceを提供して直接は依存しないようにする。このルールを基本として実装しています。今の所ざっと思いつく問題点が2つあります。結局インターフェースを見出すのが、フレームワークやライブラリによってである。PasswordEncoderInterfaceは明らかにSymfonyのPasswordEncoderInterfaceに依存しないように用意している。Symfonyの認証周りの実装が違ったらもっと違うインターフェースを用意してただろう。思うと設計の時点でSymfonyに依存しているのでは?しかしそれは果たして悪いことなのだろうか。フレームワークを使う時点である程度の影響を受けることは仕方ない。実装として依存していないことが大切なのでは?どうするのがいいのでしょうか?だれか教えてください。Doctrineには依存してしまう問題。AnnotationとDoctrineのCollectionオブジェクトは依存してしまいます。これはあえて依存させてたりします。Annotationなので、実装コードとしては影響がないという事で僕はあえて依存させています。Collectionは今回の実装サンプルでは出てきませんが、通常はHasManyやMenyToOneは大体あるわけで必ずCollectionが出てくる場面ってあります。その時は外部にはDoctrineのCollectionではなくtoArray()でArrayに変換するぐらいでいいのかなぁと。最後にこれが正解ってわけじゃないし、今の自分としてはこういう実装している程度なのでこれからもどんどん変化していく気がします。Request待っているので、ここもっとこうした方がいいとかそういうの教えてもらえると嬉しいです。