0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

FEのアーキテクチャを考えようぜ2

Posted at

DDD等のアーキテクチャ特性と目的

一般的にDDD等のドメイン中心の設計、クリーンアーキテクチャ等はそのアーキテクチャ特性に「変更容易性」「機能性」をもつから採用しようとなるわけなんですよね。
変更容易性の副次効果として構造さえわかれば「解析性」や分割して実装するので「テスト容易性」があるってだけの話で……
実際にその特性としては「変更容易性」「機能性」満たしていない、そして開発時にドメインをベースに話すことにより、コアドメインの理解が進み開発者がより事業に対してアサインしやすくなるってはなしでアーキテクチャとして実はその特性を有しているわけじゃないんです

だらだらと書いてもあれなので図表するとこれ

種別 内容
設計手法 DDD / クリーンアーキテクチャ
直接の目的 関心の分離・依存の制御・ドメイン理解の促進
副次的効果(アーキ特性への影響) 結果的に変更容易性やテスト容易性、解析性が高まる傾向

んじゃFEでも同様に行えばいいじゃんって話なんですがここでモダンなフレームワークの問題が出てきます。

React等の関心

私がReactスキーなためReactベースで語るんですが彼らの関心ってこれなんですよね

レイヤ 関心 実際の責務
UI(Presentation) 状態の描画・ユーザー操作の取得 入出力の制御・状態表示
状態管理(State / ViewModel) UIが使う値の整形・更新 APIやドメインから得たデータの一時的保持と整形
API通信層 データ取得や送信 usecaseやrepository的な立ち位置(実装上)

つまりはReact自体は
データの 真実のソース(source of truth) をサーバーに置き、それを UI上でどう見せるか(Presentation) に集中する構造だからなんですよね。
前回State Driven Architectureの構成もbackendというドメインの塊から、送られてきたものをEntityに変換してUIに接続するものです。

つまり、UI自体にはドメインは持ちえないのです
というかクリーンアーキテクチャ的に一番外側のUIにさらにクリーンアーキテクチャのドーナツ作ってどうするよ問題ですよねー。

どういう構造が正解なのか?

プロジェクトによるとしか💦

[Backend Domain]
  └─ Entities / Aggregates / Domain Services
        ↓ API(DTOやGraphQL経由で反映)
[Frontend]
  ├─ repository (API叩く)
  ├─ entity(stateとかもここかなぁ)
  ├─ UseCase(状態変化のトリガー)
  ├─ Hook(状態制御・イベント管理)
  └─ UI Components(状態描画)

  ※イメージです(2分で作ったとか言えない)

この形が一番丸くない?とも思うんです。
もっとFEにもドメイン感が欲しいよと思うんですけどね。
どうしてもこれ以上となると、コードの重複や複雑さが上がり性能問題にぶち当たります。
だからこそドメイン駆動がなんかいいらしいで語るんじゃなくて、しっかりアーキテクチャ特性から今の仕事に必要なアーキテクチャを構築する必要があるんですね。

最近の私事

DDDができますやります任せてくださいと安易に言う人によく言っているのが

「React等のフロントエンドの関心、つまり僕たちでいうところのドメインはUIにあります。
構造的・原理的に関心が違うものに、誰かが考えた“最強ドメイン構造”を適用しても、責務分離どころか構造的に破綻しますよ?」

具体名だすとミノ駆動さんとかの講演会の質問でもこの手の話題よく上がり、現実的に難しいからめちゃくちゃ言葉選んで回答しているなぁと前々から思ってはいたんですよね。

でもよくよく考えてみるとDDDの概念がよくわかっていないまま、なんとなくサーバーやスタンドアローンで動く物すべてにそれを適用しようとして、システム全体で彼は何者か?が全部抜けちゃっているんじゃないかと思うんですよ。

例えば、SPAだとブラウザ上ででっかいサーバみたいなのでUIだし分けているし、NEXT.js等のサーバーサイドレンダリング系は鯖を持つが本質はUIの塊ですしね。

記述言語が違うから、動いているサーバーがちがうからそれぞれでDDDやろうではなくて、それら全部まとめたものがDDDでFEサーバ等は一番外の層を考えている考え方で実装したほうが丸くいくんじゃないかとおもいます。

もちろん俺はNextJSだけでDBアクセスして単体でサービスとして成り立つように作るぜとかは別ですが、たいていはFEサーバーやSPAの仕組みがあり、BEのAPI叩くって使い方ですからね?

NextJSだけでサービス作ったことあるの?

もちろんですプロですから……

マネージャーの野郎ぶっ(思い出しベネット)

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?