00:03
はい、10月6日、火曜日ですね。 地獄は朝9時を回りました。
昨日は、ちょっと夜にいきなり
なんでしたっけ、ツイッタースペースでダラダラ喋る、喋り打ちをやったんですけど、はい、たくさん頂いた方は大変ありがとうございました。
で、じゃあ本日も朝活を始めていきたいと思います。
はい、えーとですね、今日は、あのー、先日ですね、10月1日に、あのー、
日本GTO協会と、あと、Nijiboxさんですね、が、えっと、主催されていた
あの、イベントですね、エンジニアイベント、えー、PostDev っていうものがありまして、
えー、で、そこでまた様々なお話とか、たくさんの良いお話っていうのが、あのー、聞けたっていうのを、あのー、ツイッターのタイムラインで見ておりました。
で、僕も参加したかったんですけど、その時、ちょうど10月1日にですね、あのー、
採用イベントがありまして、まあ、それに参加していた、
まあ、なんですか、バッティングしてしまったせいですよ、と、このお話、この勉強会を全然聞けなくてですね、で、YouTube Live もやっぱりアーカイブは今のところなさそうなので、
はい、ちょっと残念だなと思いながらですね、で、それぞれのあのスライドを公開されている方がいらっしゃったので、そのスライドを見ていこうと思っています。
で、そのうちの一つですね、やっぱりあの、僕の興味関心がある、まあ、フロントエンド周りのところですね、のお話と、
あの、僕が個人的にずっと尊敬している、あの、株式会社一級の伊藤直生さんですね、C級の伊藤直生さんが、えーと、発表されていたというところなので、そのスライドみたいなと思って、あの、今日やっていこうと思います。
もし時間が余りましたらですね、タイトル以外のもう一つの記事、別の記事で、
えー、アプリチュートリアルの体験設計の重要性についてというところを書かれている記事があったので、ちょっと短めなので、これも読めるんだったら読んでいこうかなと思っていますが、
まあ、ちょっと伊藤直生さんの記事がどれぐらい長いかわかんないので、まあ、ちょっとやっていきたいと思います。
えー、フロントエンドのパラダイムを参考にバックエンド開発を再考するタイプスクリプトによるグラフQLバックエンド開発っていう、あの、スライドをちょっと読んでいこうと思います。
あの、発表スライドですので、まあ、そんなに文章もないと思うところなので、まあ、なんか、なるべくなるべく予想しながら読む感じになると思いますけど、すいませんが、ご了承ください。
じゃあ、いきましょう。
えー、まず最初ですね。
えー、ちょっと歴史的な話から入っている感じですね。
えー、JQuery機と言っています。
はい。
まあまあ、あの、皆さんもこれだけでいろんなものを思い出される方も結構いらっしゃるんじゃないでしょうかというところですけど、はい。
まあ、MPA with JQueryですね。
昔はそのSPAとかじゃなくて、一個一個のページを独立して作っていたと。
で、それを、えー、昔はその今みたいにUIフレームワークみたいなのがたくさんあったわけではなかったので、もうJQuery一本でガリガリ書いてたっていう時代がありますと。
で、しかもまあ、JQueryで書いてたんですけど、JQueryがあまりにもうまくできすぎてですね、まあ、さすが、ジョン・レシークは天才だなって本当に思いますけどね。
はい。ってところで、ライブラリーなのに何かフレームワーク感があるような感じで、まあ一斉を封じたんですけどね。
はい。
まあ、で、JavaScriptが得意な人はいたんですけど、チームとかにね。
フロントエンド、バックエンドという役割分とは別に行われず、まあ全員が同じ領域を単位としていたというので、まあいわゆるモノリシックな開発とかも昔は全然行われてましたので、
その時の側の方を、まあJQueryで入れて少しリッチとか、少し簡単に簡略化して作りましょうみたいなのがありましたよということですね。
03:01
で、続いて、Vue.js導入機っていうのがあったんですね。
これ多分、1.93の流れかな。
Vue.js導入機のところで、Vueのフロントエンドの人とMPAっていうのが、
えーと、まだ一応共存はしてたらしいですね。
で、まあフロントエンドエンジニアとバックエンドエンジニアっていう役割分段が少しずつこうなされるようになってきたらしいです。
なるほどですね。
リアクトじゃなくてVueから入ったんですかね、これは。
はい。で、続いてNuxt時代ですね。
はい。もうこれも数年前ですけど、まあ一時期そのNuxt.jsが出た瞬間、僕副業もしてたんです、今もしてますけど、
昔、いろんな案件にお話し行ったときに、
皆さんもどんどんどんどんNuxt導入してて、Nuxtもええやんみたいな感じの流れが一時期ありましたね。
とにかく猫もシャクシもNuxtでみたいな、
まあ結局はVueでやるんですけど、そのいろんなものをラップしたりとか、
そのいろんなものの設定とかもガツンと一発でやってくれるっていうところで、
まあ結局みんなサボりたいというか楽がしたいので、
いろんなものがごちゃ混ぜになってて、
全部最初から用意してどうぞみたいなフレームワークが好きなんだろうなとちょっと思いました、はい。
で、Nuxt時代でNuxtと線が1本引かれてグラフ切れるバックエンドみたいなところの、
いわゆるフロントエンドとバックエンドの役割というのがもうはっきり明確になったと。
で、フロントエンドのみ開発するっていう担当者も増え始めたよというところですね。
はい。で、まあそうなっていたんですけど、双方の技術的関心ごとにちょっとギャップが出始めましたよと。
フロントエンドの人たちはもちろんアプリケーションのその状態管理モデルですね、はい。
まあステータ管理の方はやっぱり関心が強いと。
あとデザインシステムとかプリレンダリングとか、はい。
結局その側の方をどうリッチに表現をするかというところとかに、
まあ、興味・関心が強くなっていたというところですね。
で、バックエンドの方はもっとビジネス的なコアのお話で、
ドメインモデルだったりとかそのレイヤードアーキテクチャだったりとかですかね。
はい、あとCQRSとかその辺の関心がやっぱり強くなっていって、
やっぱりこの辺はやっぱりバックエンドエンジニアだけあって、
設計周りとか、本当にビジネスのコアのロジックのところに、
やっぱり普通とフォーカスを置かれているというところですね。
で、組織の技術年度が上がれば上がるほど、
関心ごとのギャップってのはやっぱりどんどん広がっていったよということですね。
はい、まあこれは仕方ないです。
見ているものと目指しているところが違うので、
まあ最終的にはそのシステムとかアプリケーションを作るというところには方向性は一緒だとしても、
関心を見ているところは全然違うよねというので、
まあそうなっていきますよね、ギャップはというので、はい。
で、とあるきっかけがあったそうで、
なんかこうギャップを何とかしたいってことがあったのかな。
で、新規プロジェクトが立ち上がりまして、
フロントエンドはリアクト、リレー、そしてリコイルを使ったんですけど、
ドラスティックに変わりましたね。
で、バックエンドはグラフQLを入れて、
長らくPythonでクラスを対応したクリーンアクティクチャ的な設計でやってきたんですけど、
まあ今回どうしようかというところだったそうで、
まあグラフQLバックエンドに注目をしたということですかね。
はいはいはい。
えー結構、ナクストからリアクトって結構でかいパラダイムになったと思いながら今聞いてます。
はい。
で、えーと、新規プロジェクトは小さなチームで密度高く議論して作りたい。
あーでも、これはそうですよね。
新規プロジェクトこそ、なんかいきなり大体的にチームドカンと入れるんではなくて、
小さなチームでその代わり密度濃く、はい。
連携も強くしてリアクトを進めていきたいというのは確かにあるかもしれないです。
06:00
この辺はもうなんかスタートアップと同じ感じですよね。
はい。
で、もう顧客のどんな問題をどう解決したいか。
まあっていうところで、ディスカッションをとにかく大事にしたいと。
で、フロントエンド・バックエンド関係なく対象ドメイン領域に詳しくなりたい。
どんな体験をどんなUIでどういうモデルでどんなデータ設計をして実現するのかみたいな、
初期フェーズでは全員がなるべく広くしておきたいってところですね。
これやっぱ大きいですよね。
今みたいにそう役割分担がはっきりされて、フロントエンド・バックエンド・インフラ・テクスチャーとか、
iOSとかデザインとかでいっぱい分かれますけど、
やっぱりみんなが共通認識を持ってたりとか、みんなで同じようなものを見ているっていうのはやっぱり強いですね。
チームとしてはかなり強いと思います。
もちろんやることが最終的に役割分担をして別々になっているだけってことですけど、
まあでも、そういうのを望むチームでやればいいですけど、
自分はもうスペシャリスト、バックエンドしかやりませんみたいな人もいるんだったら、
それはそれで別にその人の方向性だって話なので、
でも伊藤さんが目指しているそのチーム、新規プロダクトのチームっていうのは、
フルスタックではないにしても、そうやってみんなで共通認識とかを持って、
みんなであの物事を一緒に見てやっていきたいっていうところがあるそうですね。
早期に役割分担を行いすぎるとその関心事の分担をまた誘発してしまって、
本来思っていたその関心事の分担っていうのを解決したいってところがまた発生してしまうので、
なるべく早めに役割分担をしないように心がけたってことですかね、これは。
はい。
で、リアクトでフロントエンド開発をしてからバックエンドを書くとどうなったかっていうところを見ていきますと。
はい。
リアクトでは小さな関数を組み合わせて宣言的に書いていくと。
はい、まあこれはそうですね。リアクト書いたことある方はそのままだと思います。
はい、まあリアクトは全てJSですからね。
最終的にレンダリングされるのもJSXなんですけどそれはJSなので、
この辺がテストのしやすさってのも結構あっていいんですけどね。
はい、でバックエンドはそのクラスをたくさん書いてレイヤーをまたぐとDTOで値の詰め替えを行ってインターフェースで依存性の逆転を行ってみたいな、
はいはい、ほげほげみたいな感じでした。
まあフロントエンドだとこういうことあんまやらないよねっていう話は、
それは出ますよね、はい。
クラス、まあそもそもクラスたくさん書くってフロントエンド今全然やらないと思いますし、
今フロントエンド開発でクラスなんてキーワードを書くこと滅多にないですからね。
はい、でまだレイヤーをまたぐっていうけどそもそもレイヤーっていう概念がフロントエンドにはあんまないかもしれないですね。
ただ今後リアクトが次リリースするリアクトサーバーコンポーネントの話が出たときに、
ちょっと近い概念というのかなっていうのが出てくるかもしれないですね。
でまあそうですね、あとDTOというワードも出てこないしインターフェース、インターフェースもほぼ使わないですからね。
タイプスクリプトでインターフェースってワードが出てきはしますけど、
多分サーバーサイドで行っているインターフェースと多分意味合いが違いますね。
でまあその開発者のメンタルモデルのやっぱりギャップってすごく大きくてコンテキストスイッチの負担もやはり大きいよねっていう話をしてました。
でバックエンド開発のやり方をやっぱり再考してみたいというところで、
リアクトを使っているとフロントエンドを薄く書くことができるし関心ごとが違うのは当然ですと。
かといってやり方が違うと全く疑わないのもどうだろうというところですね。
それもまあ確かにそうですよね。
というわけでフロントエンドの状態管理はやっぱり複雑でありますと。
でその複雑なものはどう扱うか。
09:01
現時点で最良のモデルが、モデルの一つが一応リアクトのはずだという風な見込みをしていますと。
で複雑な状態管理をどう扱うかという観点でサーバーサイドも同じように考えられないのかっていうところ。
その関心はやっぱり一つにしたいというところで、
グラフQLバックエンドもタイプスクリプトで書いてみようというのが今回の一つの答えだったそうですね。
これは確かにそうかもしれないですね。
結局みんなJSでやってタイプスクリプトを使えればいいですし。
ってことはネストJS入れるのかどうかと思ったけどグラフQLでやったんですね今回はね。
っていうところです。
まあでもタイプスクリプトは使えるので、
関心ごとだったり状態だったりいろんなものの定義っていうのが同じTSの型ファイルで一元ができるのでっていうことですね。
では改めて昨今のフロントエンドのプログラミングパラタイムを考えてみようというところで、
水地さんの記事のリンクが貼られてますね。
ウープシングモダンって書いてますね。
宣言的プログラミングの時代の話が一応引用に出されていて、
その中であるんですけど、
軽く読みますね。
現代の主流というのは宣言的プログラミングであると思っている。
これはリソースの宣言とその状態遷移の手続や振る舞いの付与が中心にありますと。
一応そのWikipediaにも宣言的型プログラミングっていうのが一応リンク貼られてます。
その代表的な例がフロントエンドのリアクトとバックエンドのK8Sですね。
Kubernetesですね。
どちらも時系列に基づいた状態の宣言とフレームワーク側による状態遷移処理っていうところですね。
っていうのが基礎にありますと。
リコンシリエーションですね。
頂点っていうのが基礎にあります。
フロントエンドとバックエンドという両極端な世界でこの変化が起きたのがこの時代の反映したものであるというふうには思うと。
おっしゃってますと。
なるほどですね。
まあ確かにフロントとバックエンドは今もう完全に興味関心とか見てるものが違うってさっき言った通りで。
両極端な世界を生きてるってのはそうですねってことです。
はい。
まあでもどちらも時系列に基づいた状態の宣言とフレームワーク側による状態遷移処理だっていうところが同じなんじゃないのっていう。
その共通点を見出せたらいいんじゃないかというところですね。
はい。
で、そこでELMのアーキテクチャーののを見ていると。
はい。
一応ELMのアーキテクチャーの記事のリンクも一応貼られてますね。
まあHTMLを書いてメッセージをELMで送ってっていうことを繰り返すってことですね。
はい。
で、一応そのELMのソースコードがガーッと出てきてて。
これはさすがにちょっと音読すると難しいんであれですけど。
まあやってること何してるかっていうと。
まあいわゆるViewの方でモデルを描画しておいて、ユーザー操作に応じてイベントを発生させると。
例えばオンクリックでメッセージを送りますよっていうような感じですね。
で、ELMのランタイムがアップデート関数図の4で、
関数にはイベントの処理に応じたモデルの状態選挙の記述しておく。
一個一個手続き的にこう書いておくと。
で、その状態に合わせた処理を発火させるっていうような感じですね。
はい。
まあELM書いたことある方は結構少ないと思いますけど。
まあELMはELMで僕は結構好きですけどね。
はい。
まさに関数型っていう感じなので。
まあ最初ちょっと慣れないかもしれないし、面倒くさって思うかもしれないですけど。
ただ状態が本当に綺麗にクリアになるっていうところは大きいなって、
12:01
なんだかんだ思いますけどね。
で、その辺の説明がもうちょっと出てきて、
さっきのELMのサイクルの図があるんですけど、
ランタイムシステムってところにちょっと切り替わってますね。
いろんなランタイムがあってメッセージ発火して、
ELMの方でそれを実行すると。
で、HTMLを返してみたいな繰り返しですね。
はい。
で、これがいわゆるコマンドとイベントっていうところとリンクしてんじゃないのって話してますね。
状態遷移の関数とその外界とのやり取り、
いわゆるIOですね。
っていうのがイベントとコマンドを使ってくるくる回ってますねみたいな話でした。
はい。
で、イベントを契機に状態が遷移する。
つまり時系列に基づいた状態ですよねって言ってます。
いわゆるモデルからモデル、モデルからモデルみたいなところですね。
で、イベントに伴いその状態を遷移させて、
あとはフレームワークやランタイムで任せると。
そこの辺はそうですね。
関心事はその辺で任してしまっていいと思います。
いわゆる状態遷移の関数とランタイムやフレームワークっていうのがあって、
状態遷移の関数がコマンドを実行して、
ランタムやフレームワークっていうのがイベントを発火してみたいところですね。
はい。
で、リラックスか。
リラックスのアプリケーションデータフローの図を引用されてますね。
はい。
いわゆるイベントハンドラーのディスパッチが行われて、
ストアの方でリリューサーがガチャガチャやって、
状態を変更して、
その変更された状態でUIをまたアップデートして、
UIの方でまたユーザーが操作をしたら、
またイベントハンドラーのディスパッチが行われるっていう例のサイクルですね。
はい。
リラックスは本当に一つの答えというか、
いわゆるフラックスアーキテクチャーが生まれて、
フェイスブックから発生して、
そこからリラックスが生まれて、
一時期本当にリラックスずっと使ってたんですけど、
今だとちょっと重いなって思いつつも、
やはりあの時代に一つの答えを出したっていうのは、
功績はでかかったし、
今も全世界でリラックスは使われてますからね。
一応だんだん落ちてきてるっていうのは、
NPMトレンドでも証明されてますけど、
今はなんだかんだリコイルの方が多いんですかね。
と言ってたらリコイルのソースコードも張られてました。
ソースコード自体はテキストインプットっていうところで、
入力されたらその入力値の値を、
状態を保持しておくと。
ユーズリコイルステートっていう例のリコイルの関数があって、
それのセットテキストとテキストってところで状態を保ってますよってことですね。
はい。
リコイルっていうのは、
リラックスによる大きなグローバルステートって扱いづらい局面について、
よりスコープを小さく、
かつ、ローカルステート同様ですね。
いわゆるリューズステートですね。
ローカルステート同様にフックで宣言的に扱えるようにしたっていうところで、
リコイルを今回注目していたということですね。
さっきのエルムアーキテクチャーとか、
リラックスで発見された良いプラクティスっていうのを踏襲しつつ、
できる限り小さなスコープで状態を扱っていけると良さそうだっていう風に見てるそうですね。
これは確かにそうかもしれないですね。
両方の美味しいところを要はしていきたいっていうところで、
かつでもスコープはできる限り小さい状態で扱っていけると良いんじゃないのっていう話ですね。
手書きの絵が描いてますね。
メッセージが発生して、状態とオブジェクトっていうところに、
しかもクエスチョンが貼られてますね。
バックエンドでも同じように時系列に基づく状態遷移の視点で考えられないかっていうのが、
次の問いであります。
バックエンドの世界の主な状態っていうのは、いわゆるドメインモデルの状態ですよね。
ドメインモデルの状態を遷移させるイベントってなんだっていうと、
15:01
ドメインイベントになります。
例えばですね、やっぱり193なんですけど、
宿泊予約っていうのを例にドメインモデルを改めて考えてみましょうと。
どんな観点に注目して考えてみるべきかというところで、
例えばデータ構造だったり、ER2だったり、クラスのリストだったり、画面だったり、
いろんなものがありますよね。
いずれもですけど、静的な構造に焦点を当てている。
その視点を変えてみたいと。
動的なものですね。今まで静的なものに焦点を当てたけど、
動的なものに焦点を当ててみる。
つまりドメインイベントや状態に焦点を当ててみるとどうなるかというところですね。
で、予約の状態を改めて着目してみましょう。
いきなり予約完了からいくんですね。
予約完了という状態からどういう遷移をするかという。
カード決済済みといって、それからキャンセルが発生しますし、
宿泊済みという状態に変化することがあり得ますよねと言っています。
新規予約が完了する前からドメインモデルというのは実は存在していますよと。
その予約完了というのは今見ましたけど、
その前からドメイン自体はあります。
例えば入力未検証だったり、入力の検証済みだったり、在庫の確保済みだったりみたいなところですね。
状態は何かしらイベントを契機に遷移すると言っていますね。
予約を開始したところで入力未検証が行われて検証完了したというイベントが来たら検証済みに状態が変わる。
在庫確保したという状態が、イベントが発生して在庫確保済みというふうにシステムの状態が変わる。
予約を行ったというイベントが発生して予約完了が行われるみたいな感じで、
状態は何かしらのイベントを契機に遷移がされますよということですね。
そこで見てみると、先ほど見ていたモデルから別のモデルへの状態遷移というアーキテクチャ図が出てきますけど、
これとリンクしないかみたいな感じですね。
両端は外部とのインターフェースだというふうに言っています。
いわゆるイベントハンドラー、WebAppならルーターみたいなところと、
両端なのでDBに保存してレスポンスを返してUIに返してあげるみたいなところですね。
両極端は外部とのインターフェースであって、
基本的にさっき言ったモデルからモデルへのサイクルと同じなんじゃないのという話ですね。
これどこかで見たなというと、イベントモデルの遷移状態、外の世界というのは、
先ほど見た状態遷移の関数とランタイムやフレームワークというところですね。
何のコマンドとイベントと同じじゃないのというところです。
IO状態遷移、IOというところですね。
これ何だ?本かな?ドメインモデリングメイドファンクショナルっていう本があるんですかね。
っていうのを引用されていますね。
引用されている一つのアーキテクチャーってですね、
APIインターフェースとかインフラストラクチャーとか、
IOとPureコードとIOというところが一本の時系列に並べられていて、
コアドメインとインターフェースとかインフラストラクチャーというのが
集合の的な図で貼られています。
ちょっと音読したけど、これは見ていただくのが一番分かりやすいと思います。
いわゆるオニオンアーキテクチャーを想像してくれればいいと思います。
フロントエンドとバックエンドの状態管理のところにもう一回注目して戻りましょう。
フロントエンドの状態管理っていうのは主な関心事は
いわゆるアプリケーションの状態がフロントエンドの状態管理だと言っています。
バックエンドの状態管理は何かっていうと
18:00
主な関心事はドメインモデルとドメインオブジェクトの状態だというふうに言っています。
いわゆる管理している状態のコンテキストは違うものの
状態管理のモデル自体は似たように考えられるんじゃないのっていうふうに着目しています。
ドメインオブジェクトの状態専用、宣言的に記述しつつ
IOから分離してみましょうと。
このコンセプトで実装したと。
ELMアーキテクチャおよびFsharpDDD本を参考にいろいろやってみましたよってことですね。
このスタイルでよく使うものとしてタイプインターフェースだったり
タグ付きのユニオンですね。いわゆる触話型ってやつですけど。
リザルト型だったりいわゆる仮移化だったり
型のブランド化とかコンパニオンオブジェクトだったりとか。
逆にあまり使わないものとしてクラスだったり例外のスローだったり。
エラークラスは使いますけど例外スローはあんまり使わない。
簡単なユースケース例として図が1個また載ってますけど
タグの管理のところですね。
タグ名とアイコンがプルダウンで選択になるように
みたいな感じのUIが一応出されてます。
こんな感じのことをやってます。
続いてタグエンティティですね。
集約ルートの状態遷移着目をしましたと。
またフローズみたいなのがあって
入力があったらアンバリデイティッドになって
検証が行われたらバリデイティッドになって
何かを作成したらクリエイティッドになって
いわゆる状態遷移ですね。
ちなみにここでのクリエイティッドはあくまで
ドメインオブジェクトが作成済みの状態になった場合であって
データベースにレコードを追加したみたいな状態じゃなくて
ってことですね。あくまでドメインオブジェクトの
作成済みだそうです。
この状態についてタグのクラスを作りますか?
みたいなクエスチョンですね。
エクスポートクラスタグで
いろいろプロパティがあって
そこに型が定義されてますと。
こうなってしまうけどどうする?ってなった時に
状態遷移前には確定しないプロパティが
アンディファインドになってしまいますよね。
実態として。
それは望ましくないよなってところですね。
なので状態ごとに型を定義するっていう風に
さっきの
unvalidatedタグっていう状態の型と
validatedタグってやつと
createdタグ
っていう型ですね。
本当に状態ごとに型を一個一個作ってみたと。
状態が遷移するドメインモデルが発生するごとに
モデルの値が確定していくので
宣言ができているってところですね。
いやちょっと待ってこれ面白いな。
状態ごとに型を定義するか。
これをやると
確かにフロントとバックでも同じような共通認識が
取れるな。
make illegal states unrepresentable
っていう問題もあります。
レコードはANDでいきますと。
ユニオンはORでいきますけど
ANDの方、レコードの方は取り得る値の
種類数っていうのは各属性の直積になりますと。
例えば両方アンディファインド
もしくは両方の値が生まれるというような
使用上ありえないような状態が生まれる可能性がありますと。
逆にユニオン型
ORですね。
直和型の方は1×1×2にしかならないんですけど
使用上ありえない状態は表現できないので
ユニオン型の方がいいんじゃないの
っていう話をされてますね。
AND型ってのは確かに
良くない気がするんで
例えばインターフェースユーザーっていう型があって
型の中にメンバーIDと
ゲストIDみたいなのがあるとしましょう。
これは確かに直和型なんですけど
両方アンディファインドと両方の値が
生まれるみたいな
ありえない可能性が出てきてしまうので
それはちゃんと型として分けましょうと。
21:01
これは一般的な話ですね。
インターフェースにメンバーがあって
インターフェースのゲストっていうのはそれぞれで分けましょう
それを最後タイプユーザーの
メンバー、パイプ、ゲストみたいなので
直和型にするっていうのは良いと思いますね。
さっきも言った
Xportクラスタグで
一つの中に全部のプロパティを
バーッと書くのではなくて
それぞれの状態で型を書いていって
最後にそれを
Xportタグでパイプで
組み込まないでいく、いわゆるユニオン型にしていく
というところですね。
これだけでもすごい参考になりましたね今日は。
状態を遷移させるステップです。
関数1ですけど
1つ目にさっきのタイプバリデイティッドタグですね。
それは
引数としてモデルを受け取っていく。
そのモデルっていうのは
Unvalidatedタグですね。
Unvalidatedタグの型も
状態っていうのを引数に受け取って
レスポンスにバリデイティッドタグの型で
返してあげると。
上手いこと連携できるんですね。
状態を遷移させるステップ関数2として
クリエイティッドタグのところも同じですね。
さっきのバリデイティッドタグっていうところを
引数にして状態を作った予定という
クリエイティッドタグで返してあげると。
それぞれの状態のところで
状態が整って初めて値が確定するので
そこを自然に記述できるっていうのも
やっぱり大きいですよねっていう形です。
型も見てしまえば
今状態も確定しているし
値についてもちゃんとそこは担保できている
っていうのがやっぱりおいしいよねって言ってます。
いやー本当にいいですねこれ。
というわけで
モデルの型と関数の型によって
状態線を宣言的に記述していくと。
今の宣言的な
プログラミングのパラダイムと結構
似ているなっていうかそこに沿わすことができたな
っていう感じですね。
個別に定義した状態線への関数を繋げたいと。
でもやっぱり計算自体は途中で失敗する
可能性ってのは大いにあり得ると。
例えばドメインモデルの事前条件を乱さないエラーだったり
いわゆるバリデーションエラーだったり
MAX TAG LIMIT EXCEED
っていうところがありますね。
途中で失敗することを型で
宣言できないかっていうの。
そのためにリザルト型っていうのを今回定義したと。
なるほどね。
いやー勉強になるな、なるほど。
リザルト型で失敗の可能性のある件数を
一本道に一応合成をしていきましょうと言いました。
インポートで
NEVERTHROWっていうところから、NEVERTHROWというライブラリがあるんですけど
リザルトOKエラーっていうのを
読み込んでますと。
一個一個ファンクションで定義をしてますね。
一つ目が
IT'S UNDER 100ってやつですね。
100以下ですかっていうところを見てます。
リザルト型でナンバーとエラーっていうのを
GENETICSで適数に受け取るようにしてますと。
もう一個下の方に
リザルトOKってやつですね。
リザルトのところにOKの値と
AND ZEN AND ZEN AND ZENで繋いでいって
その中に一個一個の
今見たのはIT'S UNDER 100なんですけど
それ以外にIT'S EVENだったり
IT'S POSITIVEとかですね。
それぞれの状態がどうかっていうのを
定義しておいてそれをAND ZENで
一個一個繋いでいくという感じですね。
失敗の可能性のある計算っていうのを
一本道にどんどん合成していくっていうような
書き方をしてますね。
いわゆるメソッドジェーンみたいな書き方で
やっていくというところでした。
24:01
リザルト型で状態遷移を繋げて
一つのワークローティングを作っていく
っていうのが今回の取り組みだそうですね。
状態遷移の成功および失敗をリザルト型で
全部返してあげるようにしてあげると。
値の生成の失敗の可能性も
リザルト型で返してあげる
なのでリザルト型でさっきやった
プリミティブな関数をリザルト型で
定義したんですけど、その先の方ですね。
全体的なところもリザルトで
Generic数のバリデイティってタグと
バリデーションエラーみたいなのを
型引数として取るよみたいなのに
定義してあげるという形ですね。
リザルト型で状態遷移を繋げて
ワークフロードメインロジックも
作っていきましょうと。さっきと同じように
OKのところでモデルを渡してあげて
AND ZENでバリデイティってタグを
渡してあげて、さらにAND ZENで
クリエイティってタグを渡してあげると。
一つのワークフローっていう
ドメインロジックを作ってあげると
いうところですね。ワークフローの始まりと
終わりがいわゆる下界のインとアウト
っていうところですね。
GraphQLのResolverとRepositoryDB
パターンっていうところのワークフローを
それに接続してあげましょうと。やると
GraphQLインプットとデータベースのところの
やり取りっていうのもそのワークフローの中に
押し込むことができるってことですね。
一番最初のOKモデルってところに
GraphQLインプットを渡してあげて
AND ZENでセーブクリエイティってタグみたいな
関数を作ってあげてそこにデータベース
へのやり取りも書いてあげると。
いわゆるデータフロープログラミングっていう風に
今回は名前を付けているそうですね。
リザルト型で失敗のある計算を合成して
データの通り道としての計算過程を
作ってあります。そこにデータを掘り込むと
その中を通って超対戦した
データが得られます。データをデータのまま
その可能性、過半性を下げずに扱いたい。
結果クラスの登場機会が
なくなりますねってことでした。
失敗の分岐はリザルトで合成。リザルト型は
モダンドでやりますよってことですね。
計算が一本道になる。かつデータは普遍。
というときに認知負荷も低くなる。
ところでやっぱり計算一本道ってするのは
いろんなメリットありますねっていう。
これらをデータフロープログラミングという
常に名前があるのか伊藤名小屋さんが
名付けたのかちょっとわからないですけど
すごいしっくりくる名前ですね。
フロントエンドの比較というところですね。
時系リザルト型のデータフロープログラミング
としてのデータフロープログラミングは
いわゆるデータフローを先限的に記述する
という考え方はやっぱり同じになりましたと。
型と小さな関数の先限的な記述で
フローを組み上げますってことですね。
一方ワークフローの実装しているときの
間隔にはまだ距離があります。
ドメインイベントで状態遷移といっても
多くの場合はバリデートして入力で
ドメインモデルを更新するだけみたいな。
結果ワークフローは定期的な記述が多くなるし
フレームワークができるかもしれない。
フロントエンドはそこをリアクトで
イベントに対するモデルの状態遷移と
その状態を表現するプレゼンテーションの
記述にも集中できますと。
イベントとイベントのつなぎ合わせですね。
例はリザルド型による合成ですけど
そういうつなぎ合わせを自分で
記述しているのが未満のところは現状ですよと。
時間がないので実装の詳細は
また後日書きますってことでした。
このままではトランザクションスクリプトで
業種制が低くなってしまうと。
エンティティ型の周辺にコアドメインロジックの
関数を実装してモジュール分割するとか
ワークフローはそのコアドメインロジックを
27:00
使ってフローを組み立てる役割だけになる。
クリーンアーキテクチャのユースケースと
同じだよっていう感じですね。
従来手法に比較し記述量が少ないというところですね。
データをデータのまま運んでいるっていうところが
さっきのデータフロープログラミングで
実装したやつですね。
リザルド型でどんどんつないでいくってやつですけど
これによってデータをデータのまま
運んでいるので詰め替えて役割の異なる
別種のオブジェクトにするみたいな
必要がなくなります。
値のコピーは実際には所々やっているんですけど
ただのデータを分割代入で記述できるので
記述量は結局少なくなりますよっていうところでした。
現時点で一応やってみた感想ですけど
使用上ない状態を
作らずに済むためかなり堅牢になりました。
これもう多分この一点だけで
今回導入する価値は
全然あるって僕も感じましたね。
より複雑なワークフローを実装した場合も
結局同じ構想に収まるので認知負荷ってのは
どんどん下がりますと。
同型により計算をつなげられるよう記述する。
良い強制力が働く。
ただし&全&全、エイシンク&全
ドットマップみたいなのはさすがに読みづらい。
ハスケルのDo記法だったり
Fシャープのコンピテーション式に相当するものが欲しい。
すいません、僕かわからん。
ハスケル書いたことがないし
Fシャープは名前しか知らん。
値の詰め替えの記述がないのはやっぱり
とても嬉しいってところですね。
ここも大きいですよね。結局詰め替える記述が
ないっていうのは本当にでかいと思います。
振り返ってみて、いわゆる時系列に基づいた状態の宣言と
フレームワーク側による状態遷移処理
っていうところですけど
これはできたんじゃないかと思ってます。
まとめとして時系列に基づく状態遷移の宣言と
フレームワーク側による状態遷移
また頂点ですね。
フロントエンドはそのためのフレームワークの実装が
やっぱり充実してます。
宣言的プログラミングのプラクティスは
2022年現時点では経験的に良いものだと思ってます。
バックエンド開発もこの考え方に
収容させていくのも悪くないんじゃないの?
っていうことでした。
やってみたら結構好感触でした。
流行るかどうかは分からないですけど
フロントエンドとバックエンドのパラダイムギャップを
少なくしていきたいというのがあります。
補足が最後ありまして
タイプスクリプトに組み込みの
リザルト型はないので
neverthrowという今回のライブラリを使いました。
他にもfptsみたいな候補もあります。
リザルト型はワークフローの構成だけでなく
あらゆる場所に使います。
一方、リザルト型パズルにはまる時ももちろんあります。
紹介しきれなかったけど
プロミスもリザルトエイジングによって
リザルト化して構成はできますよと。
ドメインモデリングメイルファンクショナル
書籍の提案手法そのままだと
トランザクションスクリプトによる業種性が低くなります。
ただしIOはきちんと分離されているので
より良いトランザクションスクリプトだとは思います。
エンティティの型の周りに
ドメインロジックの関数を集めることで
その問題は解消できていると。
あらゆるプロパティに型を定義する
アクティブ的な手法をとっているが
そこは採用しませんでした。
バリオブジェクトのみたいなノミナルな型定義の
型のブランド化ですね。
オライディのタイプスクリプトの対象によって行っています。
リポジトリは必要ないと書かれていたが
集約をせっかく構成しているので
従来通りリポジトリパターンで
表的・集的単位での映像化を行っています。
なおリポジトリの中身は
プリズマを使っていると。
タイプとインターフェイスの使い分けですけど
FPTSに習っていますと。
関数がデフォルトで仮移化されないのは
30:00
仕方ないと。
時折仮移化したのを忘れてはまる。
リードオンリーは横着して使っていないです。
ちゃんと検討しないディスクですよ。
最後に参考文件があるので
見てみてください。
というわけで
ちょっと時間をオーバーしてしまいましたが
今日の朝活は以上にしたいと思います。
かなり資料がないと
これ難しいですね。
いろんなアーキテクチャーズが出てくるので
聞くだけだと
何言ってるかわからなくなったかもしれません。
大変申し訳ないです。
このスライド自体も
ツイッターでだいぶ流れていますが
改めて僕もまた流しますので
興味ある方は見てみてください。
すごく僕は参考になりましたし
どうにするかは検討しますけど。
というところで
今日の朝活は以上にしたいと思います。
本日もご参加いただいた多くの方
大変ありがとうございました。
火曜日ですね。
休みたい欲が僕は発生していますが
心強く頑張っていきたいと思います。
終了します。お疲れ様でした。
