© Chatwork 宣言的 UI 時代の クライアントサイド DDD 大考察 2022/11/26 [Sat]　CTO 室　エンジニア採用広報　高瀬 和之 Chatwork 株式会社

2019 年に Chatwork 株式会社へ フロントエンド・エンジニア としてジョインし、 リリース基盤やビデオ通話アプリケーションの開発に従事。 2020 年から エンジニア採用広報に転身 し、技術イベント運営や エンジニア採用を主業務とする。パラレルワークで講師業 も営む。 JSConf JP 2021 では、関数型プログラミング の話題で登壇しました。 自己紹介 - 高瀬 和之 (たかせ かずゆき) 2 　：@Guvalif YouTube にて アーカイブ配信中！

速習 Domain Driven Design クライアントサイドとモデル 宣言的 UI との親和性を考慮したモデル実装 1 2 3 AGENDA アジェンダ

速習 Domain Driven Design 1

そもそも DDD とは何か？ 5 Minimal Imple- mentable Modula- rized Iterative 1. 対象領域における 必要最小限かつ実装にも反映可能な "モデル" に焦点を当てて ... 2. 概念 (およびその集合) に応じて モジュール化 して ... 3. イテレーティブ に設計すること cf. エリック・エヴァンスのドメイン駆動設計 ド メ イ ン

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

問題空間 A 問題空間 C 問題空間 D 問題空間 E 問題空間 B キーワード：問題空間 (サブドメイン) と解決空間 7 問題空間 (サブドメイン) 解決空間 対象領域 (ドメイン) をそのまま扱うと 広大かつ難解な場合において、 対象領域を分割した際の一単位 単一もしくは複数の問題空間に対して、 どのように概念をモデル化して 実装しているかの影響範囲 cf. 実践ドメイン駆動設計 対象領域 解決空間

キーワード：境界づけられたコンテキスト 8 ある概念を表す "モデル" があった時に、対象領域を 分析する人ごとにモデルの解釈がわかれる 場合がある → これは、問題空間の分割に示唆を与える と同時に、モデルの適用範囲 ≒ 解決空間にも影響を与える cf. エリック・エヴァンスのドメイン駆動設計 経路 荷受け地 荷出し地 通関地点 (Optional) 経路 エッジリスト ノードリスト 窓口担当者 視点 配送計画者 視点 "経路" という概念は ... 視点を変えると別のモデル 予約コンテキスト 配送コンテキスト

クライアントサイドとモデル 2

- #1 で見たように DDD の原理・原則はシンプル - 一方で、クライアントサイドにおいては 成功した事例をほとんど聞かない - #2 では、このギャップがなぜ起こるのかを考察する

解決空間 (クライアント) 解決空間 (サーバー) 現代的なアプリケーションの構造 11 - 現代的なアプリケーションの多くは、インターネットを介したシステム同士の通信を備えている - これにより、アプリケーションを クライアントサイド と サーバーサイド に分離する設計も 取れるようになった 対象領域

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

素朴な疑問： DDD の適用が有用であるような、解決空間の与え方は？🤔

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

解決空間 (サーバー) 解決空間 (クライアント) 具体例：フォームバリデーション 15 サーバーサイドにあるモデル上の表明 (アサーション) を元にして、バリデーションエラーを 通知することもできるが、クライアントサイドにもモデルを用意することでユーザー体験を改善できる 名前を入力してください 名前モデル 表明 1：アルファベットのみか？ 表明 2：文字数が 1 〜 30 文字か？ ︙ 名前登録 API エンドポイント 利用 表明違反の 通知 POST 400 Error: 文字数が不足しています！

モデリングとユーザー体験設計の相互作用 16 先ほどは「モデルがユーザー体験設計に影響を与える」例を見たが、 「ユーザー体験設計がモデルに影響を与える」ことも同様にある → デザイナーも巻き込んだ議論のすすめ cf. オブジェクト指向 UI デザイン プレゼンテーション インタラクション モデル 対象領域

ここまでの まとめ 01 サーバーサイドの担う解決空間が十分に広い場合、 クライアントサイドで DDD のプラクティスを適用する意義は薄い 17 02 クライアントサイドの担う解決空間に対して、 ユーザー体験設計の視点によって自然にモデルを与えうる

宣言的 UI との親和性を考慮したモデル実装 3

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

再掲：DDD の実践によって構造が厚くなると思われがちなポイント 20 󰢃 誤解 󰢏 正しい解釈 DDD を実践するには、 現実を写実的にモデリングする 必要がある 実装にも反映可能なモデル にこそ価値があり、 モデルを深堀りする中で、写実的な側面からは 見いだせない構造が見つかることにも価値がある DDD を実践するには、 クラス機構を用いる 必要がある 概念に対して凝集度を高く保つ ことができるなら そもそもオブジェクト指向ですらなくてもよい DDD を実践するには、 レイヤー化アーキテクチャを用いる 必要がある レイヤー化はモジュール分割の一手段 で しかなく、モデリングの一環ではない DDD を実践するには、 スクラム開発を用いる 必要がある モデルが 恒常的にリファクタリングされる ことは 前提だが、アウトカムが定期的にある必要はない 関数型 DDD の考え方により 薄さを維持する 依存の方向が一方向になる ことだけを意識する (割愛)

関数型 DDD ≒ モデルの遷移関数とその合成 21 各タイミングにおけるモデルは interface として個別定義し、イベントに対応するように遷移関数を実装 cf. Domain Modeling Made Functional デッキ シャッフル済み デッキ シャッフル済み デッキ ＋ ハンド シャッフル ドロー

Reducer 機構への遷移関数のマッピング 22 イベントの発生は Action により Reducer 機構へ伝搬し、遷移関数を呼び出す (useReducer / Recoil / Redux など、何を用いるかはアプリケーションの規模感に応じて調整) → State 管理のありふれた仕組みに、モデルの実装が適合する UI Reducer Model t Read Model t UI Action 遷移関数実行 Selector Component

サーバーサイドとの通信はどこに置くべき？ 23 関数型 DDD においては、モデルの遷移関数は純粋であることを想定 → サーバーサイドとの通信は、その前後に接続する cf. Domain Modeling Made Functional

注意点：GraphQL ≒ Read Model 24 GraphQL がもっとも真価を発揮するのは、Read Model としてそのまま UI に適用できる場合 → すなわち、クライアントサイドの解決空間が狭い時 解決空間 (サーバー) 解決空間 (クライアント) UI のみが薄く構成される (もはや解決空間として 分離しなくてもよい) API / ユースケース※ / モデルなどが 一様に存在し、設計戦術が高い効果を持つ クライアントサイドに 価値のあるモデルが 含まれる可能性は無い → DDD の適用は無駄

まとめ 01 宣言的なクライアントサイドにおいてモデルを実装する際には、 関数型 DDD の考え方を用いることで自然な統合ができる 25 02 実際のところ、宣言的なクライアントサイド開発のあり方が、 意識せずとも DDD に適合していたとも考えることができる

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

働くをもっと楽しく、創造的に