このスライドは、2022/11/26 に開催された「JSConf JP 2022」で発表したものです。
cf. https://jsconf.jp/2022/talk/client-side-ddd-in-the-age-of-declarative-ui-grand-considerations
© Chatwork宣言的 UI 時代のクライアントサイド DDD 大考察2022/11/26 [Sat] CTO 室 エンジニア採用広報 高瀬 和之Chatwork 株式会社
View Slide
2019 年に Chatwork 株式会社へフロントエンド・エンジニア としてジョインし、リリース基盤やビデオ通話アプリケーションの開発に従事。2020 年から エンジニア採用広報に転身 し、技術イベント運営やエンジニア採用を主業務とする。パラレルワークで講師業 も営む。JSConf JP 2021 では、関数型プログラミング の話題で登壇しました。自己紹介 - 高瀬 和之 (たかせ かずゆき)2 ：@GuvalifYouTube にてアーカイブ配信中！
速習 Domain Driven Designクライアントサイドとモデル宣言的 UI との親和性を考慮したモデル実装123AGENDAアジェンダ
速習 Domain Driven Design1
そもそも DDD とは何か？5MinimalImple-mentableModula-rizedIterative1. 対象領域における 必要最小限かつ実装にも反映可能な "モデル" に焦点を当てて ...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逆説的な主張になるが、境界づけられたコンテキストが存在する ならば、隣接する 解決空間にもモデルが現れる→ 主張：ユーザー体験の設計をする視点が、クライアントサイドの担う解決空間にモデルを与えうる○○ モデルAAABBBCCC○○ モデルXXXYYYUX 設計者視点○○ 視点ユーザー体験コンテキスト ○○ コンテキスト
解決空間 (サーバー)解決空間 (クライアント)具体例：フォームバリデーション15サーバーサイドにあるモデル上の表明 (アサーション) を元にして、バリデーションエラーを通知することもできるが、クライアントサイドにもモデルを用意することでユーザー体験を改善できる名前を入力してください名前モデル表明 1：アルファベットのみか？表明 2：文字数が 1 〜 30 文字か？︙名前登録 APIエンドポイント利用表明違反の通知POST400Error: 文字数が不足しています！
モデリングとユーザー体験設計の相互作用16先ほどは「モデルがユーザー体験設計に影響を与える」例を見たが、「ユーザー体験設計がモデルに影響を与える」ことも同様にある → デザイナーも巻き込んだ議論のすすめcf. オブジェクト指向 UI デザインプレゼンテーションインタラクションモデル対象領域
ここまでのまとめ01 サーバーサイドの担う解決空間が十分に広い場合、クライアントサイドで DDD のプラクティスを適用する意義は薄い1702 クライアントサイドの担う解決空間に対して、ユーザー体験設計の視点によって自然にモデルを与えうる
宣言的 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 ModeltRead ModeltUIAction 遷移関数実行 Selector Component
サーバーサイドとの通信はどこに置くべき？23関数型 DDD においては、モデルの遷移関数は純粋であることを想定→ サーバーサイドとの通信は、その前後に接続するcf. Domain Modeling Made Functional
注意点：GraphQL ≒ Read Model24GraphQL がもっとも真価を発揮するのは、Read Model としてそのまま UI に適用できる場合→ すなわち、クライアントサイドの解決空間が狭い時解決空間 (サーバー)解決空間 (クライアント)UI のみが薄く構成される(もはや解決空間として分離しなくてもよい)API / ユースケース※ / モデルなどが一様に存在し、設計戦術が高い効果を持つクライアントサイドに価値のあるモデルが含まれる可能性は無い→ DDD の適用は無駄
まとめ01 宣言的なクライアントサイドにおいてモデルを実装する際には、関数型 DDD の考え方を用いることで自然な統合ができる2502 実際のところ、宣言的なクライアントサイド開発のあり方が、意識せずとも DDD に適合していたとも考えることができる
We are Hiring !!!26働くをもっと楽しく、創造的にクライアントサイド / サーバーサイド /デザインにいたるまで、モデルを意識しながらプロダクト開発に挑戦したい方はぜひ弊社まで！
働くをもっと楽しく、創造的に
guvalif
yuya4
takanorip
kojira
achamixx
hakubishin3
.jpg){kind=avatar}
oshanqq
peisuke
baseballyama
revcomm_inc
lemiorhan
knsg16
joker1007
jacobian
keithpitt
philhawksworth
zakiyama
bermonpainter
rmw
jensimmons
chrislema
eileencodes
gr2m
marcduiker
geeforr