Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

宣言的 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

Kazuyuki TAKASE

November 26, 2022
Tweet

More Decks by Kazuyuki TAKASE

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. 速習 Domain Driven Design クライアントサイドとモデル 宣言的 UI との親和性を考慮したモデル実装 1 2

    3 AGENDA アジェンダ
  4. 速習 Domain Driven Design 1

  5. そもそも DDD とは何か? 5 Minimal Imple- mentable Modula- rized Iterative

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

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

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

    ≒ 解決空間にも影響を与える cf. エリック・エヴァンスのドメイン駆動設計 経路 荷受け地 荷出し地 通関地点 (Optional) 経路 エッジリスト ノードリスト 窓口担当者 視点 配送計画者 視点 "経路" という概念は ... 視点を変えると別のモデル 予約コンテキスト 配送コンテキスト
  9. クライアントサイドとモデル 2

  10. - #1 で見たように DDD の原理・原則はシンプル - 一方で、クライアントサイドにおいては 成功した事例をほとんど聞かない - #2

    では、このギャップがなぜ起こるのかを考察する
  11. 解決空間 (クライアント) 解決空間 (サーバー) 現代的なアプリケーションの構造 11 - 現代的なアプリケーションの多くは、インターネットを介したシステム同士の通信を備えている - これにより、アプリケーションを

    クライアントサイド と サーバーサイド に分離する設計も 取れるようになった 対象領域
  12. 解決空間 (クライアント) 解決空間 (サーバー) 解決空間の分割とモデル分布に関する考察 12 クライアントサイドとサーバーサイドで、解決空間の広さを極端に変えてみる クライアントサイドに 価値のあるモデルが 十分に含まれる

    → DDD の適用が有用 解決空間 (サーバー) 解決空間 (クライアント) 認証 / 永続責務 などが BaaS 的に薄く構成される UI / ユースケース※ / モデルなどが 一様に存在し、設計戦術が高い効果を持つ UI のみが薄く構成される (もはや解決空間として 分離しなくてもよい) API / ユースケース※ / モデルなどが 一様に存在し、設計戦術が高い効果を持つ ※ ユーザーストーリーに対応づく、モデルの進行役を担うモジュールのこと クライアントサイドに 価値のあるモデルが 含まれる可能性は無い → DDD の適用は無駄
  13. 素朴な疑問: DDD の適用が有用であるような、解決空間の与え方は?🤔

  14. 境界づけられたコンテキストを考える 14 逆説的な主張になるが、境界づけられたコンテキストが存在する ならば、 隣接する 解決空間にもモデルが現れる → 主張:ユーザー体験の設計をする視点が、クライアントサイドの担う解決空間にモデルを与えうる ◦◦ モデル

    AAA BBB CCC ◦◦ モデル XXX YYY UX 設計者 視点 ◦◦ 視点 ユーザー体験コンテキスト ◦◦ コンテキスト
  15. 解決空間 (サーバー) 解決空間 (クライアント) 具体例:フォームバリデーション 15 サーバーサイドにあるモデル上の表明 (アサーション) を元にして、バリデーションエラーを 通知することもできるが、クライアントサイドにもモデルを用意することでユーザー体験を改善できる

    名前を入力してください 名前モデル 表明 1:アルファベットのみか? 表明 2:文字数が 1 〜 30 文字か? ︙ 名前登録 API エンドポイント 利用 表明違反の 通知 POST 400 Error: 文字数が不足しています!
  16. モデリングとユーザー体験設計の相互作用 16 先ほどは「モデルがユーザー体験設計に影響を与える」例を見たが、 「ユーザー体験設計がモデルに影響を与える」ことも同様にある → デザイナーも巻き込んだ議論のすすめ cf. オブジェクト指向 UI デザイン

    プレゼンテーション インタラクション モデル 対象領域
  17. ここまでの まとめ 01 サーバーサイドの担う解決空間が十分に広い場合、 クライアントサイドで DDD のプラクティスを適用する意義は薄い 17 02 クライアントサイドの担う解決空間に対して、

    ユーザー体験設計の視点によって自然にモデルを与えうる
  18. 宣言的 UI との親和性を考慮したモデル実装 3

  19. - #2 では、クライアントサイドに モデルが現れる条件を調べた - #3 では、モデルをソフトウェアとして どのように実装していくべきかを考察する

  20. 再掲:DDD の実践によって構造が厚くなると思われがちなポイント 20 󰢃 誤解 󰢏 正しい解釈 DDD を実践するには、 現実を写実的にモデリングする

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

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

    Recoil / Redux など、何を用いるかはアプリケーションの規模感に応じて調整) → State 管理のありふれた仕組みに、モデルの実装が適合する UI Reducer Model t Read Model t UI Action 遷移関数実行 Selector Component
  23. サーバーサイドとの通信はどこに置くべき? 23 関数型 DDD においては、モデルの遷移関数は純粋であることを想定 → サーバーサイドとの通信は、その前後に接続する cf. Domain Modeling

    Made Functional
  24. 注意点:GraphQL ≒ Read Model 24 GraphQL がもっとも真価を発揮するのは、Read Model としてそのまま UI

    に適用できる場合 → すなわち、クライアントサイドの解決空間が狭い時 解決空間 (サーバー) 解決空間 (クライアント) UI のみが薄く構成される (もはや解決空間として 分離しなくてもよい) API / ユースケース※ / モデルなどが 一様に存在し、設計戦術が高い効果を持つ クライアントサイドに 価値のあるモデルが 含まれる可能性は無い → DDD の適用は無駄
  25. まとめ 01 宣言的なクライアントサイドにおいてモデルを実装する際には、 関数型 DDD の考え方を用いることで自然な統合ができる 25 02 実際のところ、宣言的なクライアントサイド開発のあり方が、 意識せずとも

    DDD に適合していたとも考えることができる
  26. We are Hiring !!! 26 働くを もっと楽しく、 創造的に クライアントサイド /

    サーバーサイド / デザインにいたるまで、モデルを意識 しながらプロダクト開発に挑戦したい方は ぜひ弊社まで!
  27. 働くをもっと楽しく、創造的に