WEB アプリケーションのフロントエンドの DDD に関する所感
2023-09-08 追記
あれから色々な本を読んだり色々な人の意見を聞いて考えが変わった
いろいろな frontend の DDD が考えられるが、今はビジネスロジックではなくフロントエンドの仕様を表現した局所的な DDD もありだなという考え
過去にいくつか Frontend で DDD や DDD みたいなものを実装してきた
実際に目指していたのはクリーンアーキテクチャだが、クリーンアーキテクチャは DDD を目指すためのアーキテクチャという解釈の元、例に上げている
インターン先のフロントエンドのプロダクト
その度にいろいろしっくりこないことがあった
フロントエンドの DDD とバックエンドの DDD の違いってなんだろう
フロントエンドで表すビジネスロジックとバックエンドで表すビジネスロジックは違うのか?
フロントエンド(ブラウザ)のみで持つ状態を Entity として表現したコードに対して「それは Entity に含めるべきではない」という意見をもらったことがあるが、なぜそうなのか
バックエンド(正確には API Endpoint)をただの Infrastructure と考えれば、フロントエンドだけもつ状態を Entity として表現してもいいのでは(むしろそのほうがフロントエンドから見たドメイン知識としていいのでは)
フロントエンドの Entity とバックエンドの Entity の定義は(大抵の場合)揃えるべきという意見をもらったことがあるが、なぜそうなのか
DDD は外側(今回の場合バックエンド)を意識してはいけないはず、揃えてはそもそも意識していることになるのでは
究極を言えばフロントエンドのドメインとバックエンドのドメインはバラバラであってもいいのでは
ある日友達とフロントエンドで DDD を実践する是非(正確にはフロントエンドでドメイン知識を持つ是非)について話す機会があった
色々話したが…その話を反芻してまとめると
アーキテクチャは人間の限界による妥協、人間が十分に優秀ならアーキテクチャとかなくてもよい
極論みんな機械語をかけば良い
フロントエンドに本来ドメイン知識はなくてもよい、
フロントエンドとバックエンドの両方にドメイン知識をもたせるのは、状態の維持などが大変
しかし組織の問題、人間の理解の問題としてフロントエンドにドメイン知識を持たせたい理由がある
フロントエンドエンジニアはバックエンドのコードを完璧に理解できないから
フロントエンドエンジニアは API を通してバックエンドのドメインモデルのライフサイクルに思いを馳せるのが辛いから
フロントエンドとバックエンドで開発進捗や状況が異なることがあり、その差分を考慮するのが辛いから
となると最初の疑問が解決する
フロントエンドの DDD とバックエンドの DDD の違いってなんだろう
フロントエンドで表すビジネスロジックとバックエンドで表すビジネスロジックは違うのか?
ない
なぜならどちらも一つのサービスのドメインを表現するべきだから
そもそもドメインじたいが、これがフロントだから、バックだからなどを意識しないのでは
開発進捗の乖離で分かれるのはありうる
フロントエンド(ブラウザ)のみで持つ状態を Entity として表現したコードに対して「それは Entity に含めるべきではない」という意見をもらったことがあるが、なぜそうなのか
なぜならどちらもサービスの状態を表すから
ブラウザのみの状態がサービスとして重要ならあってもいいが、フロントして重要なら不要
フロントエンドの Entity とバックエンドの Entity の定義は(大抵の場合)揃えるべきという意見をもらったことがあるが、なぜそうなのか
前述の通り
感想
すべてのアーキテクチャは妥協
アーキテクチャは字面に惑わされない
フロントの DDD とかではなくサービスの DDD
フロントとバックで共通の DDD が使えないからわかれているだけ
そのアーキテクチャが解決したいことはなにか?を重要視する
発展
フロントもサーバも TypeScript ならドメイン知識を共有できるのでは
Wasm とかで共有のドメイン知識を持つのはどうだろう
OpenAPI Schema みたいなやつがドメイン知識を記述できないだろか