Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
やまたつ reduxでビジネスロジックを ゴリゴリ書く
Slide 2
Slide 2 text
● 銀の弾丸の話じゃないです ○ ビジネスロジック ( ドメイン ) がでかいフロントエンドを想定しています ○ API と routing と永続化をバランシングするのが主題のフロントエンドに於いてはうまくハマらないかも ● redux の話です ● 設計思想とかツールとか ○ 深くは語らない ○ リンクをできるだけ貼ってます 前提
Slide 3
Slide 3 text
自己紹介 ● やまたつ ● エンジニア ○ もとは Rails とか react とかのエンジニア ○ １月から株式会社 Cure App ■ ネイティブアプリエンジニア ● react native ○ 思ってたより快適に開発できるぞ ○ アプリのリリース作業が鬼のように鬼 ■ web のころは良かった ■ 自動化したい ● ツールは色々あるぞ ○ おれ、この発表が終わったらリリース自動化するんだ。。。
Slide 4
Slide 4 text
目次 ● CureApp でやっていること ● redux でビジネスロジックをどこに書く？ ○ CQRS ○ event sourcing ● redux でビジネスロジックをどうやってかく？ ○ redux-thunk の場合 ○ テストの書き方 ● action creator をドメインクライアントとしてバリバリとドメインを書くならこのへんのツー ルが使えるよ ○ 本質的にドメインをどう書くかみたいな話は端折る。つ実践ドメイン駆動設計
Slide 5
Slide 5 text
CureAppでやっていること ● 治療アプリを作ってます ● 全部 js で作ってる (universal) ○ スマホアプリ、 PC アプリ、 Web フロント、サーバーサイド ○ react, react native, electron, node.js, mongoDB, aws lambda ● universal の恩恵 ○ 型に守られる (flowtype) ○ モデル等の再利用 ● monorepo
Slide 6
Slide 6 text
monorepoのdir構成
Slide 7
Slide 7 text
JSerがビジネスロジックを ガシガシ書く
Slide 8
Slide 8 text
reduxでビジネスロジックを どこに書く
Slide 9
Slide 9 text
reduxでビジネスロジックをどこに書く こんな感じで考えてます ● redux を CQRS として捉える ● redux を event sourcing として捉える
Slide 10
Slide 10 text
reduxをCQRSとして捉える
Slide 11
Slide 11 text
reduxをCQRSとして捉える CQRS: コマンドクエリ責任分離 (Command Query Responsibility Segregation) 元々はサーバーサイドのアーキテクチャ。更新系のサーバーと取得系のサーバーを分離 する。更新系と取得系は必要とされる観点やパフォーマンスが異なるケースが多いよねっ て言う話。 取得系 ● 速度が求められる ● 永続化データを表示にとって都合 のいい形式にフォーマットするだけ ● レポートって言われたりする 更新系 ● 複雑な実装が求められる ● ビジネスロジックがつまってる ● 速度は多少犠牲になってもよい
Slide 12
Slide 12 text
reduxをCQRSとして捉える
Slide 13
Slide 13 text
reduxをCQRSとして捉える ここにビジネスロジック ここは表示のための ロジックなので ビジネスロジックでは ない single plain object
Slide 14
Slide 14 text
● redux doc で出てくる話 ● ドメインでもビジネスロジックでも無いので DDD とか難しいことを考えなくていい。 ● (state: State) => { /*view に都合のいいデータ */ } を返すだけの関数 ○ テスタタブル ○ mome 化で高速化可能 (reselect) ● state の形を考える時「表示にとって都合のいい形であること」を考えなくて良くなる ○ State を永続化にとって都合のいい形にすることに集中できる ○ State の正規化 (Normalizing State Shape) ● State と View の間の腐敗防止層になる ○ View の変更と State Shape の変更のそれぞれが、互いに波及するのを止める selector
Slide 15
Slide 15 text
action creator ● ワイヤーフレームから導き出されるユースケースの一覧 ● あとで redux-thunk の話するときに喋ります
Slide 16
Slide 16 text
reduxをevent sourcingとして捉える
Slide 17
Slide 17 text
● 状態管理手法のひとつ ● 時系列順に並んだイベントを溜めていって、必要なときにそこから読み出す ● CQRS と相性がいいって言われている reduxをevent sourcingとして捉える
Slide 18
Slide 18 text
reduxをevent sourcingとして捉える
Slide 19
Slide 19 text
● reduce * flux => redux ● action の無限長配列に対して reduce し続けることで現在の state を表現するステート マシン ● event sourcing より以下の特徴を引き継ぐ ○ event 駆動の特性 ● event sourcing と比べて失ったモノ ○ イベントストア ■ なので厳密には event sourcing ではない ● でも aggregates + event sourcing が使える！！ reduxをevent sourcingとして捉える
Slide 20
Slide 20 text
● 集約 (DDD 用語 ) を永続化する手法 ○ DDD: 設計手法の一つ ● 実践ドメイン駆動設計の付録 A に詳しく書いてある ● ビジネスロジックは集約を作り出して action に乗せて dispatch するだけでいい ○ “HOGE_CREATED”, “HOGE_EDITED” とかって actionType を付けておく ■ 指示語ではなく完了形にする派です ■ イベント駆動的に DIP できる ○ reducer がそれを観測して state に保存する ■ 永続化無知の原則 aggregates + event sourcing
Slide 21
Slide 21 text
さっきの図をもっかい見てみる ここにビジネスロジック ここは表示のための ロジックなので ビジネスロジックでは ない single plain object
Slide 22
Slide 22 text
さっきの図をもっかい見てみる ここにビジネスロジック 集約作ったり編集したり reducerのこと知らない 集約が入ってる 集約を保存 ここは表示のための ロジックなので ビジネスロジックでは ない single plain object
Slide 23
Slide 23 text
reduxでビジネスロジックを どうやって書く
Slide 24
Slide 24 text
redux-thunkの場合
Slide 25
Slide 25 text
● action creator で dispatch と getState が使えるようになるだけ redux-thunkの場合
Slide 26
Slide 26 text
● thunkAction の一つ一つがユースケースでありドメインクライアント ○ ワイヤーフレームから導き出されるユースケースの一覧 ○ CQS の原則を守るのがコツ ( だと思う ) ■ コマンドクエリ分離原則 ● 戻り値返すなら副作用起こすな ● 副作用起こすなら戻り値返すな ■ dispatch が唯一の副作用 ● dispatch は空 Promise 以外の戻り値を返さない ● 環境固有 API へのアクセスはここに直接書かない ○ routing, storage, alert, blue tooth, cammera ○ middleware に 薄く 実装する ○ node 環境で実行できないコードはテストを書く ROI が低い ■ カバレッジ 100% を目指すことが正義では無い ■ ロジックの本質部分をテスタブルにして、そしてテストを書く redux-thunkの場合
Slide 27
Slide 27 text
action creator
Slide 28
Slide 28 text
middleware (ajax)
Slide 29
Slide 29 text
middleware (routing)
Slide 30
Slide 30 text
テストコード (redux doc)
Slide 31
Slide 31 text
このテストコードを爆速で書きたい！ アーキテクチャをテスタブルにする
Slide 32
Slide 32 text
テスタブルにするために ● clean であるべきだと思う ● 右は clean architecture の図です ● 多重円構造自体は onion architecture の話 なので端折ります ○ 層の数は何層でもいいってことだけ 知っておいてください ● 内側に向かって依存している ● 内側は外側を知らない ○ api も永続化も画面も知らない ● 内側ほど clean に作られているべき ○ 画面に依存しない ○ 実行環境に依存しない ○ 外部サービスに依存しない ○ フレームワークに依存しない ○ ライブラリに依存しない ● 中心にビジネスロジック ( ドメイン ) があるべき
Slide 33
Slide 33 text
action creatorをドメインクライアン トとしてバリバリとドメインを書く ならこのへんのツールが使える よ
Slide 34
Slide 34 text
● オブジェクト指向で書く ○ immutablejs の record で書く ○ ライブラリ使って頑張る ■ seamless-immutable 、 mori 、 dot-prop-immutable 、 immutability-helper ■ power-assign ○ phenyl-redux 。。。 ● 関数型で書く ○ 勉強中 ツールとか
Slide 35
Slide 35 text
power-assignの使い方 1
Slide 36
Slide 36 text
power-assignの使い方 2 mongodb docs
Slide 37
Slide 37 text
● オブジェクト指向で書く ○ まず集約を小さく設計する ○ それでもオブジェクトを immutable に編纂する必要はある ■ immutablejs の record で書く ■ ライブラリ使って頑張る ● seamless-immutable 、 mori 、 dot-prop-immutable 、 immutability-helper ● power-assign ■ phenyl-redux 。。。 ● 関数型で書く ○ 勉強中 ドメインの書き方
Slide 38
Slide 38 text
phenyl-reduxの使い方
Slide 39
Slide 39 text
phenyl-reduxの概要 ● phenyl というのがサーバーサイドフレームワーク ● 裏側は mongoDB, dynamoDB とかを選べる ● power-assign の第二引数は plain object ● つまり action に乗せれる ● redux state と mongoDB を同時に変更してくれるのが phenyl-redux ● dan 氏が言ってた serializable でコラボレート環境を実装しやすい特性を活かしてる
Slide 40
Slide 40 text
● オブジェクト指向で書く ○ まず集約を小さく設計する ○ それでもオブジェクトを immutable に編纂する必要はある ■ immutablejs の record で書く ■ ライブラリ使って頑張る ● seamless-immutable 、 mori 、 dot-prop-immutable 、 immutability-helper ● power-assign ■ phenyl-redux 。。。 ● 関数型で書く ○ 勉強中 ドメインの書き方
Slide 41
Slide 41 text
関数型でドメインを書く
Slide 42
Slide 42 text
● この辺は個人の感想でしかないです ● redux で clean architecture を突き詰めたらここだと思う ● 欲しいものが tc39 にはある ○ パターンマッチ ○ 部分適用 ○ switch 式、 if 式 ○ pipeline-operator ● 参考になりそうな本 ○ F# で DDD する本 ○ OCaml に似てる者同士として flowtype と相性が良さそう ■ flowtype は果たして clean なのか ○ scala 方面の本もいいよね 関数型でドメインを書く
Slide 43
Slide 43 text
おわり
Slide 44
Slide 44 text
キュアアップではドメインをゴリゴ リ書きたいReact Native書きたい nodejs書きたい医療で誰かを救 いたい日本初の治療アプリを作 りたいJSエンジニアを絶賛募集し ています。
Slide 45
Slide 45 text
ご清聴ありがとう ございました