Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

redux domain ビジネスロジック

yamatatsu

March 14, 2018
Tweet

Transcript

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

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

    とかのエンジニア ◦ 1月から株式会社 Cure App ▪ ネイティブアプリエンジニア • react native ◦ 思ってたより快適に開発できるぞ ◦ アプリのリリース作業が鬼のように鬼 ▪ web のころは良かった ▪ 自動化したい • ツールは色々あるぞ ◦ おれ、この発表が終わったらリリース自動化するんだ。。。
  3. 目次 • CureApp でやっていること • redux でビジネスロジックをどこに書く? ◦ CQRS ◦

    event sourcing • redux でビジネスロジックをどうやってかく? ◦ redux-thunk の場合 ◦ テストの書き方 • action creator をドメインクライアントとしてバリバリとドメインを書くならこのへんのツー ルが使えるよ ◦ 本質的にドメインをどう書くかみたいな話は端折る。つ実践ドメイン駆動設計
  4. CureAppでやっていること • 治療アプリを作ってます • 全部 js で作ってる (universal) ◦ スマホアプリ、

    PC アプリ、 Web フロント、サーバーサイド ◦ react, react native, electron, node.js, mongoDB, aws lambda • universal の恩恵 ◦ 型に守られる (flowtype) ◦ モデル等の再利用 • monorepo
  5. reduxをCQRSとして捉える CQRS: コマンドクエリ責任分離 (Command Query Responsibility Segregation) 元々はサーバーサイドのアーキテクチャ。更新系のサーバーと取得系のサーバーを分離 する。更新系と取得系は必要とされる観点やパフォーマンスが異なるケースが多いよねっ て言う話。

    取得系 • 速度が求められる • 永続化データを表示にとって都合 のいい形式にフォーマットするだけ • レポートって言われたりする 更新系 • 複雑な実装が求められる • ビジネスロジックがつまってる • 速度は多少犠牲になってもよい
  6. • redux doc で出てくる話 • ドメインでもビジネスロジックでも無いので DDD とか難しいことを考えなくていい。 • (state:

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

    し続けることで現在の state を表現するステート マシン • event sourcing より以下の特徴を引き継ぐ ◦ event 駆動の特性 • event sourcing と比べて失ったモノ ◦ イベントストア ▪ なので厳密には event sourcing ではない • でも aggregates + event sourcing が使える!! reduxをevent sourcingとして捉える
  8. • 集約 (DDD 用語 ) を永続化する手法 ◦ DDD: 設計手法の一つ •

    実践ドメイン駆動設計の付録 A に詳しく書いてある • ビジネスロジックは集約を作り出して action に乗せて dispatch するだけでいい ◦ “HOGE_CREATED”, “HOGE_EDITED” とかって actionType を付けておく ▪ 指示語ではなく完了形にする派です ▪ イベント駆動的に DIP できる ◦ reducer がそれを観測して state に保存する ▪ 永続化無知の原則 aggregates + event sourcing
  9. • thunkAction の一つ一つがユースケースでありドメインクライアント ◦ ワイヤーフレームから導き出されるユースケースの一覧 ◦ CQS の原則を守るのがコツ ( だと思う

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

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

    seamless-immutable 、 mori 、 dot-prop-immutable 、 immutability-helper ▪ power-assign ◦ phenyl-redux 。。。 • 関数型で書く ◦ 勉強中 ツールとか
  12. • オブジェクト指向で書く ◦ まず集約を小さく設計する ◦ それでもオブジェクトを immutable に編纂する必要はある ▪ immutablejs

    の record で書く ▪ ライブラリ使って頑張る • seamless-immutable 、 mori 、 dot-prop-immutable 、 immutability-helper • power-assign ▪ phenyl-redux 。。。 • 関数型で書く ◦ 勉強中 ドメインの書き方
  13. phenyl-reduxの概要 • phenyl というのがサーバーサイドフレームワーク • 裏側は mongoDB, dynamoDB とかを選べる •

    power-assign の第二引数は plain object • つまり action に乗せれる • redux state と mongoDB を同時に変更してくれるのが phenyl-redux • dan 氏が言ってた serializable でコラボレート環境を実装しやすい特性を活かしてる
  14. • オブジェクト指向で書く ◦ まず集約を小さく設計する ◦ それでもオブジェクトを immutable に編纂する必要はある ▪ immutablejs

    の record で書く ▪ ライブラリ使って頑張る • seamless-immutable 、 mori 、 dot-prop-immutable 、 immutability-helper • power-assign ▪ phenyl-redux 。。。 • 関数型で書く ◦ 勉強中 ドメインの書き方
  15. • この辺は個人の感想でしかないです • redux で clean architecture を突き詰めたらここだと思う • 欲しいものが

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