reduxでビジネスロジックをゴリゴリ書く

Transcript

1. やまたつ reduxでビジネスロジックを ゴリゴリ書く

2. • 銀の弾丸の話じゃないです ◦ ビジネスロジック ( ドメイン ) がでかいフロントエンドを想定しています ◦ API

   と routing と永続化をバランシングするのが主題のフロントエンドに於いてはうまくハマらないかも • redux の話です • 設計思想とかツールとか ◦ 深くは語らない ◦ リンクをできるだけ貼ってます 前提

3. 自己紹介 • やまたつ • エンジニア ◦ もとは Rails とか react

   とかのエンジニア ◦ １月から株式会社 Cure App ▪ ネイティブアプリエンジニア • react native ◦ 思ってたより快適に開発できるぞ ◦ アプリのリリース作業が鬼のように鬼 ▪ web のころは良かった ▪ 自動化したい • ツールは色々あるぞ ◦ おれ、この発表が終わったらリリース自動化するんだ。。。

4. 目次 • CureApp でやっていること • redux でビジネスロジックをどこに書く？ ◦ CQRS ◦

   event sourcing • redux でビジネスロジックをどうやってかく？ ◦ redux-thunk の場合 ◦ テストの書き方 • action creator をドメインクライアントとしてバリバリとドメインを書くならこのへんのツー ルが使えるよ ◦ 本質的にドメインをどう書くかみたいな話は端折る。つ実践ドメイン駆動設計

5. CureAppでやっていること • 治療アプリを作ってます • 全部 js で作ってる (universal) ◦ スマホアプリ、

   PC アプリ、 Web フロント、サーバーサイド ◦ react, react native, electron, node.js, mongoDB, aws lambda • universal の恩恵 ◦ 型に守られる (flowtype) ◦ モデル等の再利用 • monorepo

6. monorepoのdir構成

7. JSerがビジネスロジックを ガシガシ書く

8. reduxでビジネスロジックを どこに書く

9. reduxでビジネスロジックをどこに書く こんな感じで考えてます • redux を CQRS として捉える • redux を

   event sourcing として捉える

10. reduxをCQRSとして捉える

11. reduxをCQRSとして捉える CQRS: コマンドクエリ責任分離 (Command Query Responsibility Segregation) 元々はサーバーサイドのアーキテクチャ。更新系のサーバーと取得系のサーバーを分離 する。更新系と取得系は必要とされる観点やパフォーマンスが異なるケースが多いよねっ て言う話。

    取得系 • 速度が求められる • 永続化データを表示にとって都合 のいい形式にフォーマットするだけ • レポートって言われたりする 更新系 • 複雑な実装が求められる • ビジネスロジックがつまってる • 速度は多少犠牲になってもよい

12. reduxをCQRSとして捉える

13. reduxをCQRSとして捉える ここにビジネスロジック ここは表示のための ロジックなので ビジネスロジックでは ない single plain object

14. • redux doc で出てくる話 • ドメインでもビジネスロジックでも無いので DDD とか難しいことを考えなくていい。 • (state:

    State) => { /*view に都合のいいデータ */ } を返すだけの関数 ◦ テスタタブル ◦ mome 化で高速化可能 (reselect) • state の形を考える時「表示にとって都合のいい形であること」を考えなくて良くなる ◦ State を永続化にとって都合のいい形にすることに集中できる ◦ State の正規化 (Normalizing State Shape) • State と View の間の腐敗防止層になる ◦ View の変更と State Shape の変更のそれぞれが、互いに波及するのを止める selector

15. action creator • ワイヤーフレームから導き出されるユースケースの一覧 • あとで redux-thunk の話するときに喋ります

16. reduxをevent sourcingとして捉える

17. • 状態管理手法のひとつ • 時系列順に並んだイベントを溜めていって、必要なときにそこから読み出す • CQRS と相性がいいって言われている reduxをevent sourcingとして捉える

18. reduxをevent sourcingとして捉える

19. • reduce * flux => redux • action の無限長配列に対して reduce

    し続けることで現在の state を表現するステート マシン • event sourcing より以下の特徴を引き継ぐ ◦ event 駆動の特性 • event sourcing と比べて失ったモノ ◦ イベントストア ▪ なので厳密には event sourcing ではない • でも aggregates + event sourcing が使える！！ reduxをevent sourcingとして捉える

20. • 集約 (DDD 用語 ) を永続化する手法 ◦ DDD: 設計手法の一つ •

    実践ドメイン駆動設計の付録 A に詳しく書いてある • ビジネスロジックは集約を作り出して action に乗せて dispatch するだけでいい ◦ “HOGE_CREATED”, “HOGE_EDITED” とかって actionType を付けておく ▪ 指示語ではなく完了形にする派です ▪ イベント駆動的に DIP できる ◦ reducer がそれを観測して state に保存する ▪ 永続化無知の原則 aggregates + event sourcing

21. さっきの図をもっかい見てみる ここにビジネスロジック ここは表示のための ロジックなので ビジネスロジックでは ない single plain object

22. さっきの図をもっかい見てみる ここにビジネスロジック 集約作ったり編集したり reducerのこと知らない 集約が入ってる 集約を保存 ここは表示のための ロジックなので ビジネスロジックでは ない

    single plain object

23. reduxでビジネスロジックを どうやって書く

24. redux-thunkの場合

25. • action creator で dispatch と getState が使えるようになるだけ redux-thunkの場合

26. • thunkAction の一つ一つがユースケースでありドメインクライアント ◦ ワイヤーフレームから導き出されるユースケースの一覧 ◦ CQS の原則を守るのがコツ ( だと思う

    ) ▪ コマンドクエリ分離原則 • 戻り値返すなら副作用起こすな • 副作用起こすなら戻り値返すな ▪ dispatch が唯一の副作用 • dispatch は空 Promise 以外の戻り値を返さない • 環境固有 API へのアクセスはここに直接書かない ◦ routing, storage, alert, blue tooth, cammera ◦ middleware に 薄く 実装する ◦ node 環境で実行できないコードはテストを書く ROI が低い ▪ カバレッジ 100% を目指すことが正義では無い ▪ ロジックの本質部分をテスタブルにして、そしてテストを書く redux-thunkの場合

27. action creator

28. middleware (ajax)

29. middleware (routing)

30. テストコード (redux doc)

31. このテストコードを爆速で書きたい！ アーキテクチャをテスタブルにする

32. テスタブルにするために • clean であるべきだと思う • 右は clean architecture の図です •

    多重円構造自体は onion architecture の話 なので端折ります ◦ 層の数は何層でもいいってことだけ 知っておいてください • 内側に向かって依存している • 内側は外側を知らない ◦ api も永続化も画面も知らない • 内側ほど clean に作られているべき ◦ 画面に依存しない ◦ 実行環境に依存しない ◦ 外部サービスに依存しない ◦ フレームワークに依存しない ◦ ライブラリに依存しない • 中心にビジネスロジック ( ドメイン ) があるべき

33. action creatorをドメインクライアン トとしてバリバリとドメインを書く ならこのへんのツールが使える よ

34. • オブジェクト指向で書く ◦ immutablejs の record で書く ◦ ライブラリ使って頑張る ▪

    seamless-immutable 、 mori 、 dot-prop-immutable 、 immutability-helper ▪ power-assign ◦ phenyl-redux 。。。 • 関数型で書く ◦ 勉強中 ツールとか

35. power-assignの使い方 1

36. power-assignの使い方 2 mongodb docs

37. • オブジェクト指向で書く ◦ まず集約を小さく設計する ◦ それでもオブジェクトを immutable に編纂する必要はある ▪ immutablejs

    の record で書く ▪ ライブラリ使って頑張る • seamless-immutable 、 mori 、 dot-prop-immutable 、 immutability-helper • power-assign ▪ phenyl-redux 。。。 • 関数型で書く ◦ 勉強中 ドメインの書き方

38. phenyl-reduxの使い方

39. phenyl-reduxの概要 • phenyl というのがサーバーサイドフレームワーク • 裏側は mongoDB, dynamoDB とかを選べる •

    power-assign の第二引数は plain object • つまり action に乗せれる • redux state と mongoDB を同時に変更してくれるのが phenyl-redux • dan 氏が言ってた serializable でコラボレート環境を実装しやすい特性を活かしてる

40. • オブジェクト指向で書く ◦ まず集約を小さく設計する ◦ それでもオブジェクトを immutable に編纂する必要はある ▪ immutablejs

    の record で書く ▪ ライブラリ使って頑張る • seamless-immutable 、 mori 、 dot-prop-immutable 、 immutability-helper • power-assign ▪ phenyl-redux 。。。 • 関数型で書く ◦ 勉強中 ドメインの書き方

41. 関数型でドメインを書く

42. • この辺は個人の感想でしかないです • redux で clean architecture を突き詰めたらここだと思う • 欲しいものが

    tc39 にはある ◦ パターンマッチ ◦ 部分適用 ◦ switch 式、 if 式 ◦ pipeline-operator • 参考になりそうな本 ◦ F# で DDD する本 ◦ OCaml に似てる者同士として flowtype と相性が良さそう ▪ flowtype は果たして clean なのか ◦ scala 方面の本もいいよね 関数型でドメインを書く

43. おわり

44. キュアアップではドメインをゴリゴ リ書きたいReact Native書きたい nodejs書きたい医療で誰かを救 いたい日本初の治療アプリを作 りたいJSエンジニアを絶賛募集し ています。

45. ご清聴ありがとう ございました