Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
reduxでビジネスロジックをゴリゴリ書く
yamatatsu
March 14, 2018
Programming
10
5k
reduxでビジネスロジックをゴリゴリ書く
redux domain ビジネスロジック
yamatatsu
March 14, 2018
Tweet
Share
Other Decks in Programming
See All in Programming
CSE360 Tutorial 07
javiergs
PRO
0
100
Value and Record Types
hschwentner
0
550
engineer
spacemarket
0
960
Beyond Micro Frontends: Frontend Moduliths for the Enterprise @wad2022
manfredsteyer
PRO
0
130
IE Graduation (IE の功績を讃える)
jxck
20
12k
Oracle REST Data Service: APEX Office Hours
thatjeffsmith
0
750
VisualProgramming_GoogleHome_LINE
nearmugi
1
230
マルチプロダクト×非構造化データ×機械学習を支えるデータ信頼性
akino
0
130
Terraform Plan/Apply結果の自動通知
ymmy02
0
280
How we run a Realtime Puzzle Fighting Game on AWS Serverless
falken
0
250
Managing Error Messages with your Oracle Database REST APIs
thatjeffsmith
0
130
Amazon Aurora の v1 が EOL になるので 10 クラスタアップグレードして出てきたノウハウ
dekokun
0
860
Featured
See All Featured
Pencils Down: Stop Designing & Start Developing
hursman
112
9.8k
Support Driven Design
roundedbygravity
86
8.5k
Fantastic passwords and where to find them - at NoRuKo
philnash
27
1.5k
Building Flexible Design Systems
yeseniaperezcruz
310
34k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
351
21k
Practical Orchestrator
shlominoach
178
8.6k
The World Runs on Bad Software
bkeepers
PRO
57
5.3k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
105
16k
How GitHub Uses GitHub to Build GitHub
holman
465
280k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
100
5.9k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
4
510
GraphQLの誤解/rethinking-graphql
sonatard
28
6.6k
Transcript
やまたつ reduxでビジネスロジックを ゴリゴリ書く
• 銀の弾丸の話じゃないです ◦ ビジネスロジック ( ドメイン ) がでかいフロントエンドを想定しています ◦ API
と routing と永続化をバランシングするのが主題のフロントエンドに於いてはうまくハマらないかも • redux の話です • 設計思想とかツールとか ◦ 深くは語らない ◦ リンクをできるだけ貼ってます 前提
自己紹介 • やまたつ • エンジニア ◦ もとは Rails とか react
とかのエンジニア ◦ 1月から株式会社 Cure App ▪ ネイティブアプリエンジニア • react native ◦ 思ってたより快適に開発できるぞ ◦ アプリのリリース作業が鬼のように鬼 ▪ web のころは良かった ▪ 自動化したい • ツールは色々あるぞ ◦ おれ、この発表が終わったらリリース自動化するんだ。。。
目次 • CureApp でやっていること • redux でビジネスロジックをどこに書く? ◦ CQRS ◦
event sourcing • redux でビジネスロジックをどうやってかく? ◦ redux-thunk の場合 ◦ テストの書き方 • action creator をドメインクライアントとしてバリバリとドメインを書くならこのへんのツー ルが使えるよ ◦ 本質的にドメインをどう書くかみたいな話は端折る。つ実践ドメイン駆動設計
CureAppでやっていること • 治療アプリを作ってます • 全部 js で作ってる (universal) ◦ スマホアプリ、
PC アプリ、 Web フロント、サーバーサイド ◦ react, react native, electron, node.js, mongoDB, aws lambda • universal の恩恵 ◦ 型に守られる (flowtype) ◦ モデル等の再利用 • monorepo
monorepoのdir構成
JSerがビジネスロジックを ガシガシ書く
reduxでビジネスロジックを どこに書く
reduxでビジネスロジックをどこに書く こんな感じで考えてます • redux を CQRS として捉える • redux を
event sourcing として捉える
reduxをCQRSとして捉える
reduxをCQRSとして捉える CQRS: コマンドクエリ責任分離 (Command Query Responsibility Segregation) 元々はサーバーサイドのアーキテクチャ。更新系のサーバーと取得系のサーバーを分離 する。更新系と取得系は必要とされる観点やパフォーマンスが異なるケースが多いよねっ て言う話。
取得系 • 速度が求められる • 永続化データを表示にとって都合 のいい形式にフォーマットするだけ • レポートって言われたりする 更新系 • 複雑な実装が求められる • ビジネスロジックがつまってる • 速度は多少犠牲になってもよい
reduxをCQRSとして捉える
reduxをCQRSとして捉える ここにビジネスロジック ここは表示のための ロジックなので ビジネスロジックでは ない single plain object
• redux doc で出てくる話 • ドメインでもビジネスロジックでも無いので DDD とか難しいことを考えなくていい。 • (state:
State) => { /*view に都合のいいデータ */ } を返すだけの関数 ◦ テスタタブル ◦ mome 化で高速化可能 (reselect) • state の形を考える時「表示にとって都合のいい形であること」を考えなくて良くなる ◦ State を永続化にとって都合のいい形にすることに集中できる ◦ State の正規化 (Normalizing State Shape) • State と View の間の腐敗防止層になる ◦ View の変更と State Shape の変更のそれぞれが、互いに波及するのを止める selector
action creator • ワイヤーフレームから導き出されるユースケースの一覧 • あとで redux-thunk の話するときに喋ります
reduxをevent sourcingとして捉える
• 状態管理手法のひとつ • 時系列順に並んだイベントを溜めていって、必要なときにそこから読み出す • CQRS と相性がいいって言われている reduxをevent sourcingとして捉える
reduxをevent sourcingとして捉える
• reduce * flux => redux • action の無限長配列に対して reduce
し続けることで現在の state を表現するステート マシン • event sourcing より以下の特徴を引き継ぐ ◦ event 駆動の特性 • event sourcing と比べて失ったモノ ◦ イベントストア ▪ なので厳密には event sourcing ではない • でも aggregates + event sourcing が使える!! reduxをevent sourcingとして捉える
• 集約 (DDD 用語 ) を永続化する手法 ◦ DDD: 設計手法の一つ •
実践ドメイン駆動設計の付録 A に詳しく書いてある • ビジネスロジックは集約を作り出して action に乗せて dispatch するだけでいい ◦ “HOGE_CREATED”, “HOGE_EDITED” とかって actionType を付けておく ▪ 指示語ではなく完了形にする派です ▪ イベント駆動的に DIP できる ◦ reducer がそれを観測して state に保存する ▪ 永続化無知の原則 aggregates + event sourcing
さっきの図をもっかい見てみる ここにビジネスロジック ここは表示のための ロジックなので ビジネスロジックでは ない single plain object
さっきの図をもっかい見てみる ここにビジネスロジック 集約作ったり編集したり reducerのこと知らない 集約が入ってる 集約を保存 ここは表示のための ロジックなので ビジネスロジックでは ない
single plain object
reduxでビジネスロジックを どうやって書く
redux-thunkの場合
• action creator で dispatch と getState が使えるようになるだけ redux-thunkの場合
• thunkAction の一つ一つがユースケースでありドメインクライアント ◦ ワイヤーフレームから導き出されるユースケースの一覧 ◦ CQS の原則を守るのがコツ ( だと思う
) ▪ コマンドクエリ分離原則 • 戻り値返すなら副作用起こすな • 副作用起こすなら戻り値返すな ▪ dispatch が唯一の副作用 • dispatch は空 Promise 以外の戻り値を返さない • 環境固有 API へのアクセスはここに直接書かない ◦ routing, storage, alert, blue tooth, cammera ◦ middleware に 薄く 実装する ◦ node 環境で実行できないコードはテストを書く ROI が低い ▪ カバレッジ 100% を目指すことが正義では無い ▪ ロジックの本質部分をテスタブルにして、そしてテストを書く redux-thunkの場合
action creator
middleware (ajax)
middleware (routing)
テストコード (redux doc)
このテストコードを爆速で書きたい! アーキテクチャをテスタブルにする
テスタブルにするために • clean であるべきだと思う • 右は clean architecture の図です •
多重円構造自体は onion architecture の話 なので端折ります ◦ 層の数は何層でもいいってことだけ 知っておいてください • 内側に向かって依存している • 内側は外側を知らない ◦ api も永続化も画面も知らない • 内側ほど clean に作られているべき ◦ 画面に依存しない ◦ 実行環境に依存しない ◦ 外部サービスに依存しない ◦ フレームワークに依存しない ◦ ライブラリに依存しない • 中心にビジネスロジック ( ドメイン ) があるべき
action creatorをドメインクライアン トとしてバリバリとドメインを書く ならこのへんのツールが使える よ
• オブジェクト指向で書く ◦ immutablejs の record で書く ◦ ライブラリ使って頑張る ▪
seamless-immutable 、 mori 、 dot-prop-immutable 、 immutability-helper ▪ power-assign ◦ phenyl-redux 。。。 • 関数型で書く ◦ 勉強中 ツールとか
power-assignの使い方 1
power-assignの使い方 2 mongodb docs
• オブジェクト指向で書く ◦ まず集約を小さく設計する ◦ それでもオブジェクトを immutable に編纂する必要はある ▪ immutablejs
の record で書く ▪ ライブラリ使って頑張る • seamless-immutable 、 mori 、 dot-prop-immutable 、 immutability-helper • power-assign ▪ phenyl-redux 。。。 • 関数型で書く ◦ 勉強中 ドメインの書き方
phenyl-reduxの使い方
phenyl-reduxの概要 • phenyl というのがサーバーサイドフレームワーク • 裏側は mongoDB, dynamoDB とかを選べる •
power-assign の第二引数は plain object • つまり action に乗せれる • redux state と mongoDB を同時に変更してくれるのが phenyl-redux • dan 氏が言ってた serializable でコラボレート環境を実装しやすい特性を活かしてる
• オブジェクト指向で書く ◦ まず集約を小さく設計する ◦ それでもオブジェクトを immutable に編纂する必要はある ▪ immutablejs
の record で書く ▪ ライブラリ使って頑張る • seamless-immutable 、 mori 、 dot-prop-immutable 、 immutability-helper • power-assign ▪ phenyl-redux 。。。 • 関数型で書く ◦ 勉強中 ドメインの書き方
関数型でドメインを書く
• この辺は個人の感想でしかないです • redux で clean architecture を突き詰めたらここだと思う • 欲しいものが
tc39 にはある ◦ パターンマッチ ◦ 部分適用 ◦ switch 式、 if 式 ◦ pipeline-operator • 参考になりそうな本 ◦ F# で DDD する本 ◦ OCaml に似てる者同士として flowtype と相性が良さそう ▪ flowtype は果たして clean なのか ◦ scala 方面の本もいいよね 関数型でドメインを書く
おわり
キュアアップではドメインをゴリゴ リ書きたいReact Native書きたい nodejs書きたい医療で誰かを救 いたい日本初の治療アプリを作 りたいJSエンジニアを絶賛募集し ています。
ご清聴ありがとう ございました