Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

宣言的 UI 時代のクライアントサイド DDD 大考察 / Client-side DDD i...

宣言的 UI 時代のクライアントサイド DDD 大考察 / Client-side DDD in the Age of Declarative UI

このスライドは、2022/11/26 に開催された「JSConf JP 2022」で発表したものです。

cf. https://jsconf.jp/2022/talk/client-side-ddd-in-the-age-of-declarative-ui-grand-considerations

TAKASE Kazuyuki

November 26, 2022
Tweet

More Decks by TAKASE Kazuyuki

Other Decks in Technology

Transcript

  1.        © Chatwork 宣言的 UI 時代の クライアントサイド DDD 大考察 2022/11/26

    [Sat] CTO 室 エンジニア採用広報 高瀬 和之 Chatwork 株式会社
  2. 2019 年に Chatwork 株式会社へ フロントエンド・エンジニア としてジョインし、 リリース基盤やビデオ通話アプリケーションの開発に従事。 2020 年から エンジニア採用広報に転身

    し、技術イベント運営や エンジニア採用を主業務とする。パラレルワークで講師業 も営む。 JSConf JP 2021 では、関数型プログラミング の話題で登壇しました。 自己紹介 - 高瀬 和之 (たかせ かずゆき) 2  :@Guvalif YouTube にて アーカイブ配信中!
  3. そもそも DDD とは何か? 5 Minimal Imple- mentable Modula- rized Iterative

    1. 対象領域における 必要最小限かつ実装にも反映可能な "モデル" に焦点を当てて ... 2. 概念 (およびその集合) に応じて モジュール化 して ... 3. イテレーティブ に設計すること cf. エリック・エヴァンスのドメイン駆動設計 ド メ イ ン
  4. DDD のよくある誤解 6 󰢃 誤解 󰢏 正しい解釈 DDD を実践するには、 現実を写実的にモデリングする

    必要がある 実装にも反映可能なモデル にこそ価値があり、 モデルを深堀りする中で、写実的な側面からは 見いだせない構造が見つかることにも価値がある DDD を実践するには、 クラス機構を用いる 必要がある 概念に対して凝集度を高く保つ ことができるなら そもそもオブジェクト指向ですらなくてもよい DDD を実践するには、 レイヤー化アーキテクチャを用いる 必要がある レイヤー化はモジュール分割の一手段 で しかなく、モデリングの一環ではない DDD を実践するには、 スクラム開発を用いる 必要がある モデルが 恒常的にリファクタリングされる ことは 前提だが、アウトカムが定期的にある必要はない
  5. 問題空間 A 問題空間 C 問題空間 D 問題空間 E 問題空間 B

    キーワード:問題空間 (サブドメイン) と解決空間 7 問題空間 (サブドメイン) 解決空間 対象領域 (ドメイン) をそのまま扱うと 広大かつ難解な場合において、 対象領域を分割した際の一単位 単一もしくは複数の問題空間に対して、 どのように概念をモデル化して 実装しているかの影響範囲 cf. 実践ドメイン駆動設計 対象領域 解決空間
  6. キーワード:境界づけられたコンテキスト 8 ある概念を表す "モデル" があった時に、対象領域を 分析する人ごとにモデルの解釈がわかれる 場合がある → これは、問題空間の分割に示唆を与える と同時に、モデルの適用範囲

    ≒ 解決空間にも影響を与える cf. エリック・エヴァンスのドメイン駆動設計 経路 荷受け地 荷出し地 通関地点 (Optional) 経路 エッジリスト ノードリスト 窓口担当者 視点 配送計画者 視点 "経路" という概念は ... 視点を変えると別のモデル 予約コンテキスト 配送コンテキスト
  7. 解決空間 (クライアント) 解決空間 (サーバー) 解決空間の分割とモデル分布に関する考察 12 クライアントサイドとサーバーサイドで、解決空間の広さを極端に変えてみる クライアントサイドに 価値のあるモデルが 十分に含まれる

    → DDD の適用が有用 解決空間 (サーバー) 解決空間 (クライアント) 認証 / 永続責務 などが BaaS 的に薄く構成される UI / ユースケース※ / モデルなどが 一様に存在し、設計戦術が高い効果を持つ UI のみが薄く構成される (もはや解決空間として 分離しなくてもよい) API / ユースケース※ / モデルなどが 一様に存在し、設計戦術が高い効果を持つ ※ ユーザーストーリーに対応づく、モデルの進行役を担うモジュールのこと クライアントサイドに 価値のあるモデルが 含まれる可能性は無い → DDD の適用は無駄
  8. 解決空間 (サーバー) 解決空間 (クライアント) 具体例:フォームバリデーション 15 サーバーサイドにあるモデル上の表明 (アサーション) を元にして、バリデーションエラーを 通知することもできるが、クライアントサイドにもモデルを用意することでユーザー体験を改善できる

    名前を入力してください 名前モデル 表明 1:アルファベットのみか? 表明 2:文字数が 1 〜 30 文字か? ︙ 名前登録 API エンドポイント 利用 表明違反の 通知 POST 400 Error: 文字数が不足しています!
  9. 再掲:DDD の実践によって構造が厚くなると思われがちなポイント 20 󰢃 誤解 󰢏 正しい解釈 DDD を実践するには、 現実を写実的にモデリングする

    必要がある 実装にも反映可能なモデル にこそ価値があり、 モデルを深堀りする中で、写実的な側面からは 見いだせない構造が見つかることにも価値がある DDD を実践するには、 クラス機構を用いる 必要がある 概念に対して凝集度を高く保つ ことができるなら そもそもオブジェクト指向ですらなくてもよい DDD を実践するには、 レイヤー化アーキテクチャを用いる 必要がある レイヤー化はモジュール分割の一手段 で しかなく、モデリングの一環ではない DDD を実践するには、 スクラム開発を用いる 必要がある モデルが 恒常的にリファクタリングされる ことは 前提だが、アウトカムが定期的にある必要はない 関数型 DDD の考え方により 薄さを維持する 依存の方向が一方向になる ことだけを意識する (割愛)
  10. 関数型 DDD ≒ モデルの遷移関数とその合成 21 各タイミングにおけるモデルは interface として個別定義し、イベントに対応するように遷移関数を実装 cf. Domain

    Modeling Made Functional デッキ シャッフル済み デッキ シャッフル済み デッキ + ハンド シャッフル ドロー
  11. Reducer 機構への遷移関数のマッピング 22 イベントの発生は Action により Reducer 機構へ伝搬し、遷移関数を呼び出す (useReducer /

    Recoil / Redux など、何を用いるかはアプリケーションの規模感に応じて調整) → State 管理のありふれた仕組みに、モデルの実装が適合する UI Reducer Model t Read Model t UI Action 遷移関数実行 Selector Component
  12. 注意点:GraphQL ≒ Read Model 24 GraphQL がもっとも真価を発揮するのは、Read Model としてそのまま UI

    に適用できる場合 → すなわち、クライアントサイドの解決空間が狭い時 解決空間 (サーバー) 解決空間 (クライアント) UI のみが薄く構成される (もはや解決空間として 分離しなくてもよい) API / ユースケース※ / モデルなどが 一様に存在し、設計戦術が高い効果を持つ クライアントサイドに 価値のあるモデルが 含まれる可能性は無い → DDD の適用は無駄
  13. We are Hiring !!! 26 働くを もっと楽しく、 創造的に クライアントサイド /

    サーバーサイド / デザインにいたるまで、モデルを意識 しながらプロダクト開発に挑戦したい方は ぜひ弊社まで!