4. Not Just ORM

テクスタイフウェムはピクスタで働くエンジンやデザイナーによるフィジスブログ テクスタもポットキャスト版です。 ポスタは私、CTOの野菜一月と目ます。 直近では私が強調者として参加したパーフェクトルビオンレイルズ 増保快定版について、フィジスコモンの渡さんと話ししていきたいと思います。 渡さん今日もよろしくお願いします。 はい、よろしくお願いします。 はい。 前回までの振り返りなんですけど、 1Aピソードで一切ずつ取り扱うという進行を今までしてきて、 前回はパーフェクトルビオンレイルズの第11層の3日設、 サービスオブジックと大財にして毎見uwレデータモデルについて話しました。 これで11層が終わったので、 今回からの12層の複雑なuseケースを実現するという商に突入しますと。 今回は第1層のuseケースとモデルっていうのが大財になりますと。 今日何を話すかっていうのが一番時間をかけて考えたんですけど、 とりあえず回テーマとしては、 レイルズのアクティブレイクをのの招待について話ししたいなというふうに思ってます。 これなんでこのテーマを選んだかというと、 このテーマについて話そうとすると、 useケースとかについても、 大切がuseケースをモデルっていうテーマなんですが、 これについてもカバーできるんで、 この話が一番良かろうというふうに持って今回持ってきましたという感じです。 なので今回もレイルズのアクティブレイクをの招待というのを話すまでに、 何個か必要な前提知識があるので、 これを順番にさらっていきながら、 最後に本題に入るっていう、 前回みたいなサイルでいきたいというふうに思っています。 でですね、じゃあ1個ずつ行くんですけど、 まず、 これなんでアクティブレイクをの話するのに、 ここからなんだっていうふうに思われる方も言うと思うんですけど、 レイヤードアキティクチャーですね。 についてまず話していきたいなっていうふうに思ってます。 僕の理解なんですけど、 ちょっとこれレイヤードアキティクチャーについて話すにはだってそもそも、 なんかいい、 まあ、委員用できる使用がないかなっていうふうに、 お持ち探ししたら、 またもや、前回お登場しましたけど、 カーシマさんのスカップオックスを見つけて、 これだなというふうに思ったんで、 まあ、この内容にそってちょっと話すんですけど、 カーシマさんのコースクラップオックスによると、 これ、まださんって、これます、ちょっとご存じだとながらっていうふうにお聞きしたいんですけど、 カーシマさんのキジイだと、 レイヤードアキティクチャーっていうのを、 まず最初に体系だったか、 書いたのは多分、 パターンオリンピッドソフトやアキティクチャーっていう魔法があって、 これが限定になろうというふうにおっしゃってるんですね。 で、僕このキジ見つけたときに、 あ、そんな方があるのかと思って、 アマゾンで早速フルーホンを購入したんですけど、 で、まだ読んでないですが、話すで。 わたさんって、この本ってご存じですか。 うん、知ってます。 あの、アキティクチャーパターンについて伸べた代表的な本です。 あの、デザインパターンのご風に対応する形のアキティクチャーパターンを、 変算した本、ポーザって呼ばれてます。 POSA。 そうですね。 なるほど。 で、 絶班になってしまった本ですね。 なるほど。 なので、ちょっと絶班になっちゃってんだけど、 僕はまだ読んでないっていうのもあって、 このカーシアさんのこの内容に沿って魔法があったんですけど、 まあレイヤードアキティクチャーって何ですかっていうふうに、 なったときに、あのシステムに何個かこう、構成様子があると思うんですけど、 まあこれをまあ中小度でこう、レイヤーを作ってこう分けていきますと。 うん。 それで、上位のレイヤーは自分の隣の階のレイヤーにしか基本的には、 映像してはいけないっていう、なんで僕らが普通に、 あの、ウェブアプリケーションとか作るときに自然とばやっていることですよね。 っていうのをちゃんとこう体転だって出来してる。 これがレイヤードアキティクチャーですよねっていうふうになってますと。 それで、多分これ重要なことは僕を負たさると思ってて、 一つはレイヤーを、じゃあ何個作るべきなのかっていうのが別にこのレイヤードアキティクチャでは、 特に定義されていない限定されていない。 まあっていう事と、あともう一つは基本的に、 世の中のシステムのアキティクチャーっていうのは、 結構レイヤードアキティクチャーもしくは、 そろちょっと許めたもしくは変更した、 回手であるっていう事なんかなというふうに思っていて、 で、例えばちょっと例をいくつか出すんですけど、 ヘッキスサーゴナルアキティクチャーとか、 あとそれからそれと似たようなの何個が、 まとめたのクリーンアキティクチャーとかがあると思うんですけど、 これはレイヤードアキティクチャーだと、 一番目のレイヤーってプレゼンテーションレイヤーだって、 その真ん中がドメンレイヤーとかになって、 で、まっしゃがそのインフラストラクチャーとか、 データソースが言われる、まあ、そうに大体になるんですけど。 レイヤードアキティクチャーだと、 プレゼンテーションはドメンに存して、 まあそういうふうに、なるんですけど、 ドメンインから見たら、 まあデータソースもプレゼンテーションソーも、 どちらも実装の詳細やロットというふうに、 捉えてインターフェストかを使って、 ドメンインからデータソースへの いぞんっていう矢印の方向を弱点させて、 データソースがドメンの方に、 まあ、いぞんするみたいな形にしたのが、 まあ僕はヘッキスサーゴナルアキティクチャーとか、 クリーンアキティクチャーっていう、 まあ理解なんですけど、 そういう、こう、いぞんの方向変えた足であったりとか、 あとそれから隣にしかいぞんしたいけないっていうふうに、 まあ、いってるんですけど、 ちょっとそれを緩めて、 一コストバスでしたの、 レイヤはいぞんしてもいいんですよみたいなっていうのが、 したりとか、まあそういうようなのが、 レイヤードアキティクチャーの足、 として存在する。 僕はそういう理解なんですけど、 お互いさん的には、今の話聞いててどうでしょうか? 基本的には、そうなといだと思ってて、 レイヤードアキティクチャー、 レイヤーに分けるっていうのが、 よく、僕たちドメインの世界で話をしてしまいがちだけど、 多分、コンピュータギッシャンにとって、 一番、 とイメージしやすいのは、 OSIの3ションモデル。 ネットワーク、物理装合って、 データリンク装合って、 ネットワーク装合って、 トランスポート装合って、 セッション装合って、 プレゼンテーション装合って、 フリケーション装合ってあれね。 が、 レイヤーリングのイメージとしては、 一番イメージしやすいのかなっていうのは、 ネットワークの理解としては、 レイヤーと、 工場の関係的なと理解しやすいかなと思ってて、 上の装に行けばいくほど、 中小的になっていき、 というか、 アフリケーション的になっていき、 下の装に行けばいくほど、 物理装、 本当に電話線とか、 そういう世界になっていくというような話ですよね。 レイヤーいくつで話をしているのか、 レイヤーの7なのかとか、 3なのかとか、 そういうような話になっていくわけですよね。 それをそういった、 その、 直接、 下の装に 遺存していて、 で、 上の装に対しては、 中小を提供すると、 いうような装を重ねていくことによって、 必要な知識というのを、 減らすというのが、 レイヤー、 開きて、 レイヤーだフィアキちゃの大事なところですよね。 物理的な接続とか、 コネクターのピンの数とか、 コネクターのアクテム、 ネットワークのプログラミングできますよね。 ていうのは、 適切に中小化、 各装が適切に中小化してくれているからであるという話ですよね。 それを、 私たちはウェブのシステムとかウェブだけじゃないな。 システムな開きてくちゃに対して、 やはり、 その、 いくつかの、 その装を重ねていることによって、 全体の理解を、 高速使用というふうにしたわけですよね。 なので、 高速をそう中小度でレイヤーわけして、 で、中小度とか、 そうですね、 まあ中小度なのかな。 下のレイヤーが、 提供する機能を使って、 上のレイヤーに 意味付けを与えるみたいなのか、 そんなような、 感じの構図になっているわけですよね。 だから、開レイヤーが提供する機能によって、 上位レイヤーに、 上位レイヤーが必要とする機能を提供する、 みたいな関係になっている。 で、まあ、プレゼンテーション、 ドメイン、データソースとか、 いくつかの、 3レイヤー、 4レイヤーとかの構成になっているという話ですよね。 またですね。 ドメインオブジェクトとか、 ドメインモデルの方が、 データベースとか、 そのデータモデルよりも、 重量が長い。 あるいは、 技術的な詳細に 遺存しないのだから、 そしたら、 遺存の向きが逆だろう。 という話を、 写真目なんですよね。 それまでは、 ドメインロジックは、 データベースに遺存していた、 データベースの方が下のレイヤーだが、 なんだけど、 そうじゃなくて、 いやデータベース下のレイヤーじゃなく ねって話になったんですね。 で、その後、 見るフィーよみたいな形が無理じゃなくて話になったんですよね。 そう、 重ねてって下のレイヤーに遺存していくよって話だけど、 いや、 そしたら、 ドメインが、 一番下だと、 なんか、 うまい形になりませんねって話になって、 そうじゃなくて、 6かけにしよう。 なぜ6かけを、 あした細が選んだのか、 僕覚えてないんだけど、 何かが6かけにしようって話になったの。 で、6かけって、 まあ、 その意味だと、 システムの知識の中間行なす、 ドメインオブジェクトが、 価値を提供する、 アイテムレイヤーって、 別に、 コントローラーとかだけじゃないよね。 ということを、 個案をいたかったんですよね。 だから、 ポートとアダプターというアキテクチャパターンを作ったんです。 適切なコナルアキテクチャは、 ポートポーターアダプタースってやつと、 ひとくみになってるんだけど、 ですぐに、 例えば、 映像伺したい。 オブジェクトを映像伺したい。 オブジェクトを映像伺したいというのは、 つまり、 プロセスを超えて、 情報を、 長い時間を待たりで、 情報を伝達したいとか、 そういうような話ですよね。 単名のオブジェクトじゃなくて、 長い、長い機能オブジェクトを使う。 つくりたいけどでもそれがずっとメモリ上に 入させるわけに行かないからどこかに いらっしゃらなきゃいけないだからそのために 映像不可という概念が必要なわけですよね その映像不可の対象って別に データベースだけじゃなくてもいいよねとかいろいろ あるわけですねなんか最初の方はファイルで作ってで これがその道にちもさちもいかなくなったらリレーションの データベースに映すのでもいいんじゃないのとか データ構造はまあまあ安定してるけどそのデータ構造を 確診するデータストアって意外と動きますよね でそれに映像不可に遺存している ドメイオブジェクトが引っ張られて ドメイオブジェクトに対して影響が及ぶとか変更が入るっていうのは これは全然望んでないよなっていう話 なんだから映像不可の仕組み自体は ドメイオブジェクトが映像不可に遺存するんじゃなくて 映像不可の仕組みの方がドメイオブジェクトの方を向いている ドメイオブジェクトを映像不可する仕組みあるんだけど ドメイオブジェクト側は映像不可の仕組みは知らない つまり 色んな向きを逆にすれば ドメイオブジェクトはもっと長い長い期点は設計が長い期になる という話ですね安定して長い期なで安定したもの一番勝ちが高いものを一番安定させて 一番設計を長い期にしたいわけですよね というのがこれがクリーンアキテクチャーとか 平気さくののアキテクチャーが大事にしていたことであるとより安定した方向に遺存するべきだ 映像不可とかデータベースとかって 安定しているとまでは言えないのでまま安定してんだけどそれでも安定していた言えないので だからそういう向きの遺存というのは逆転させましょうというのがクリーンアキテクチャーの考え方です そうですね あちのみに途中でなんで弊貴さんをなら聞き来ちゃうがロッカッケーだのか問題っていうのはあるんですけど これあの ロッカッケである意味っていうのは僕はないと思ってて あないよ あない人じゃみないです中心にあのドメインがってそのわりに実踏詳細が取りかこまれているっていう このタムの構図がすごい重要で だからあの別に円でもいいんですよねだからね うんクリーンアキテクチャーでは円になっちゃったけど なんだろうな あー思い出したなんか正ノートでできることがしたけど そうですねでもあとちょっとすみません僕があの研究を忘れてしまったがワードさんの今の話でできたこととしてはファイラーとかは レイヤーの数っていうのがこう3つだというふうによくあの言っててであのもう何度もこのテクスタイフムで出てきてる パタンボーエンタープライズアプリケーションアキテクチャーでは プレゼンテーションととめいとデタソースの3レイヤーからなる あのアキテクチャーを中心にも説明しますっていうふうに 言って始まってるんですね日本がなんで決まってないとはいえ大体3レイヤーもしくはそれをちょっと増やしてやつみたいな ああいう事になることは分んじゃないかなという印象です僕の中では レイヤーの数ね名やの数はまぁ正直人によっていろいろ 増言しているので うんと少なく数えると3つだろうし ああああああああああさあさらに少なくするとドメイントそれ以外なのか もっとも単純なもんでいえば2つドメイントそれ以外でそうじゃなくて3つみたいのが多くてプレゼンテーションドメインデータソースみたいね スーとか3レイヤーになってんだけどまぁ他にもいろいろありますのでなんかフロイドもありねスクって人のレイヤリングパターンとか サイモンブランかなのレイヤーとか コアジェツイレイヤーのパターンとかまぁいろいろあるけどまぁだいたいん 3つぐらいに捉えておけばいいかなくらいの感じですよね 4つ3つ4つぐらいかな 確かに数え方が違う問題はあれかもしれないですねはい でえっとまぁっていうのがレイヤーですっていう話をした後にではさっきからのドメインっていう言葉が出てくるんで まあ次にドメインレイヤーの話をちょっとしたいなというふうに思ってますとで ここの話がですね 特に僕とかはもういきなり最初からオブジェクトしこう設計 あのズブズブで始まったのであのエンジンやとしてのチャレオがなので 何を話したいかっていうとそのPOEAだとドメインレイヤーっていうのを構成する方法として3つありますと いやそれ何かっていうとトランザクションスクリプトとドメイモデルとテーブルモジュルです で僕はもうそのエンジンやとしてキャリオを始めた時から ドメインモデルでそれを構成する方法っていうのしかやってきてないんですよ なのでトランザクションスクリプトとかも話を聞けばなんか多分こういうことがなみたいな っていうのがコードとしてこうイメージできるんですけど ハーチできている感じじゃないんですよ なんでおあさんにお聞きしたかったことしては僕は 話としては理解できるんだけどちゃんと実感できてないトランザクションスクリプトとか あとテーブルモジュルとか 待っていうのがどういうものだったのかとかあとちょっと気になってるのが あの多分まださんとかがキャリオを始めた時とかはまだ全然 トランザクションスクリプトとかバリバリ書いてたんじゃないかなというように思ってて なんかそのあたりを話とかも聞けたら嬉しいなと思ってちょっと話を振るんですけど なるほど ドメインロジックが記述されるドメインのレイヤーを構成するパターンとして 3つありますトランザクションスクリプトドメイモデルテーブモジュルターって まあアクティブレコードをレイルズのアクティブレコードはドメインモデルを構成する ための構成物だからだからまあレイルズからキャリオを始めたらドメインモデル中心になるって話ですよね でトランザクションスクリプトは その意味だとレイルズでイメージするならレイルズのアクティブレコードのモデルに 一切手を入れないでください えーとクラッドありますねセーブか セーブは使ってもいいけどモデルのクラスにメソード定義したダメ はいはいローデータゲートへとして扱ってくださいってことですね そうでスコープも作っちゃダメンというようなしばりを負けると どうすんのこれってなるでしょもう今なってますはい でどうすんのこれってなって諦めて コントローラーにめちゃくちゃロジックを書き始める っていうとまあ自動感がありませんね なのでじゃあコントローラーに普段書くロジックをじゃあどっかに書くかっていうので横に 映してサービスト名前付けたりいろいろ名前付けるかもしれないけど 鉄付き的なロジックとかを書き始めますと いうのがそれがトランザクションスクリプトのイメージですかね だからもっと原始的なやつでいうとアクティブレコードってそれでもまだ おっしゃるだからそうじゃなくてトランザクションスクリプトと綴になるのが 大体なんだろうねローデータゲートへとかテーブルデータゲートへとか というパターンなんですけどよそりゃSQL名前SQLで書いて コリコリにロジックを構成していくっていうのが一番原始的なトランザクションスクリプトで それだと本当に辛いので せめてSQLを名前SQLをコード中に書くのやめませんかって 名前SQLだけはせめてどっかに閉じ込めたきましょうよと いうので閉じ込める先というのが テーブルデータゲートへとかローデータゲートへというパターンになるわけですね のでなんかファインドバイ IDみたいなとか incer insertとかappデータとかデリートみたいなメソッドが並んでいるだけど その代わりSQL分自体はその中にインペーサルでいて でそれをから戻ってくるデータ型を使って プログラミンロジックのプログラミンができる ようにしようというのがそれがトランザクションスクリプトの世界ですと なるほど 1インジニアの立場から聞いてると もうやばそうな匂いしかしないですけど でも多分そのインジニアを 複数や取ってこうなんか何かを作るっていう立場に立って考えると トランザクションスクリプトことに多分文業っていうか 平列に作れますよねこれ そうそうそうそうな通りですよねだから多分そういうモデルに置いては トランザクションスクリプトの方がいいじゃんっていう風に たつしかも作って脳品したらそれで終わりとか メンティシャクティみたいなっていう状態になったら 意外と最適化になりそうだという感じはなんかなんとなく さわりをしたいので そうですよねので結構 状況によってはトランザクションスクリプトっていうのは 有効なんですね今一体のパターンもそうだしなんてかな 文業しやすいみたいなところはあるにはありましたね そのなんてか立て割り横割にどっちもしやすいんですよ なぜかっていうと 闇のリソース文化みたいなあってなけれど SQLがかけなくてプログラミング言語はかける人と プログラミング言語はあんまり得意じゃないけど SQLとか得意ないデータベースもありが得意ない人がたくさんいて でその人たちを効率的に平列で開発して 文業してもらうためにはどうしたらいいかなっていうと ドメインモデルを中心におくんじゃなくて まず各機能を建てに割っていきますと そしてその各機能のうちロジックを作る人と SQLを各人にさらに文業して テーブルデータゲートウェイとか ローデータゲートウェイみたいなSKLが の隠蔽されるSQLを書く人と その隠蔽されたSKLを 隠せるかされた一チャン隠蔽化されたな 隠蔽化されたSKLを使って ロジックを組み立てる人に分けると 上手い具合に いろんな技術者の人たちを 特異分野の異技術者の人たちを 効果的に分業してもらうことが できるというような 第一部プロジェクトとかだと あったりするというようなパターン なのがわけですよね なのでデメリットとしては もう絶対に多分超服が発生している と思うんですよ そのトランザクションスクリプトの中で じゃあそれを 継続的にあの品種と終わりじゃなくて 継続的に 国会全式期待ですっていうふうになったときに 多分すごい大変ですよね そうそうですね そういった保守性に関するグラフって ハタンブエンタープライザープレケーション 起きてきちゃう中にはありましたよね しても 俺は用書しか持ってないからなんですけど ああ 乗ってますね ドメインロジックのその 複雑策と変更コストの話しか だからこれ時間は入ってないな でも時間も同じくですよね だんだんだんだん時間を 応ぐとに保守性の面だと トランザクションスクリプトの 超複雑とかそのあたりの問題とか は基盤を向いてくるんだけど まあこれあとはもう大きいプロジェクト の場合だと その責任がはっきり分かれてる から ここを直す責任は誰だれですよって はっきりしてる場合は お願いしますすれば大体それが うまくいったりするっていうところあるので コードの共同所に言うとは 違う世界の そうですねちょっと違う世界ですね 僕が生きてる世界とは まあそれはそれでよっしゃして あるんですがそういうような そうやって回っているところもある って話です もしそういう大戦になってんだったら トランザクションスクリプトと ローデータゲートへとかテール データゲートへの方が 合理的という話になるんですね それがだからアプリケーションアーキテクチャー はコンテクストにコンテクストチュアル であるっていう話です 状況につきしたと思って 話ですね あとあのテーブルモジュールっていう のがあって 僕これトランザクションスクリプ というよりも全然イメージできてないんですけど これは何ですか これってあの僕も あんなんてかなこれある程度その 製品とか 特定のアキテクチャーアリッキーの話になってて だいたいそのビジュアルベーシックとか デルファイとか Cシャープとかマイクロソフト系の作り方に ターンを走っているやり方なので その僕もそのご理々に使っていたわけではないんですよ なんだけどディレーショナデータベース の基本となるデータが立って まあ二次元の表ですよね でその二次元の表に対して その二次元の表を 効率的にやり取りするAPIみたいなものが 製品のAPIとしてAPIてからイブラリー というようなデータ型って言うわけ 二次元のデータベースを元にした データをうまく扱う データ型みたいなものを暮らすみたいなもですね 提供しているプラットフォームがあって それを使うと 例えばWindowsアプリケーションとか 特に業務アプリケーションとかって 正直二次元の表具をうまく扱えれば いいっていう世界いっぱいあるんですよね マスターメンテとか そしたらよするに二次元の表というのが クライアント側に戻っていて クライアント側でその二次元の表編集して この二次元の表をデータベースに反映 よろしくというと バチンと反映されるうまいこと インサートとかプデートとかディリートとかに分解されて 反映されるみたいなモジュールがあったら それ楽じゃって話になるわけですね なるほどなるほど テーブルをこういうふうに買いましたっていうのが入力になって それをうまくハンドリングできる あの作り方っていうのね テーブルモジュールみたいな感じなんですかね テーブルモジュールはなので うまくデータベースを扱えるその製品が 廃墓にあるというのを前提にして そうするとその 例えばCシャップだと データテーブルっていうやつか 本当に僕もCシャップそんなに詳しくないのがあるなんですけど そのファウラなパターン目で言うとレコードセット でジャバーで言うとリザルトセットからさらに 進化させたローセットっていうクラスがあって そのローセットってやつで なんてかない二次元表の扱いで大事なのは データベースから接続を切らなきゃいけないんですよね 変な話じゃけどクライエントがに戻すためには そうですね でクライエントはに戻してなんかごちゃごちゃやって 戻ってきたやつを再接続して回じするみたいな それ話になりますよね でそのあたりをうまいことを扱ってくれる リッチな二次元コンポーネントみたいなのがあれば そういつベースにして作ったっていいんじゃないみたいな そういうような考え方があったという話ですね あのウェブの世界になると 正直あのまりないので あまりそういうのは使ってないって話なんですけど ただ二次元表うまく扱えるコンポーネント 廃後に置いったドメインロジックであれば その協力な道具があるのであれば その協力な道具を使って ドメインロジックを書いてもいいよね というところはあってなので テーブルモジュールっていうのは そのドメインロジックを そういった協力な二次元表とかのコンポーネントを使いながら 構成してもいいじゃないかというような考え方ですね あすごい理解できました 僕最初POEA読んだときにレコードセット 中にオブジェクトが入ってる 入ってすかなぐらいのモンガラっていうふうに思っちゃうんですよ なんですけど多分それにいろんなベンティーな APIが入ってて 無茶苦茶ベンティーに扱える状況っていうのが 製品によっては存在して 多分その時に言うこのアーキテクチャーなんだというのが 今すごいわかりました そういうことかなと思ってます ので自体がWebの3ティアのモデルになってたら なんかよくわからんねみたいな感想でみんな読んでた感じ だから独初会パターンベンタプライズアップイケーションアップテクチャーの 現象の独初会やったときも Microsoftケンチーズにめちゃくちゃ強い人を に来ていただいて こう実はこういうことなんだよねみたいな説明してもらったりしたという感じです すごい今ので温度感じたわけました なるほど ちなみにあれですね このレイヤーってドミンレイヤーって さっきレイヤーの数の発信が出ましたけど さらに分割されることが一般的であるというか よくありますよねっていうのが これもPEo eaに書いてあって それで前回の役所の復習になってしまうんですけど このときにドメインモデルとは別に この上に別のレイヤーとして配置されるものが 作るっていうことが多くて これをサービスレイヤーっていうふうに読んだりとか DDだとアプリケーションサービスだし クリーンアクティクチャーだと Yusukezっていうふうに よわれたりするものが配置されることが多いですと でちょっとこれ絶対言葉がよくないようだっていうふうに 僕はちょっと思ってるんですけど Yusukezって全然別の意味じゃないですか もともと そうです アクターってまあそのシステム使わせておいて それとシステムが特定の目的を達成するために 行うこう1年のやり取りのものだっていうふうに 僕は理解してるんですけど このまあYusukezと あとレイヤーにこうYusukezって名前つけるときのYusukezって 多分全然違うと思ってて なんかちょっとこのあたりも まんまりこれをYusukezっていうような 良くないんじゃないかなっていうふうには 思ってるんですけど まあそういうふうに ドメインモデルた別に別のレイヤーが こうできるということが多いですよっていう まあ私がありますね そうですね YusukezはYumlを作った3人の人の人に いばやこぶそんという人が 作った概念だと認識してて Yumlの中の人間だったよね 人間があって 箱の中のダイエント戦でつながって言う あれですね あれがだから ガンソイスケースというか あとアクターとシステムがある特定の目的を 達成するために行うような1年の想像さやみたいなしで そのあとそのYusukezっていうのは 弱権定義の道具っていうわけでいいのかな どういうことをシステムを通じてやろうとしているのか という弱権を立体化するための 方法として使われたわけじゃね Yusukezくど開発事実戦外でとかもそんな感じですし あとは アリスタコバン自体もYusukezの 良い本を書いてたけど 多分もう絶盤だってんだけど さまざまな中小度でのYusukezというものが どうやってそのシステム開発の特に書件において 弱権の明確かに役に出すかというのを 述べてたりしたので Yusukezっていうと そっちのイメージがとても強いんだけど なぜかその言葉が違ったところに マッピングされて復活してきてると 言うところはあるなって感じですよね はい すみませんちょっと 今のが若干出せになってしまったんですけど 重要話で で今ので 大体こうドメインレイヤっていうのについては あの話したからと思うんで次行くんですけど ただですね今 ドメインレイヤの話をしてる中で 次僕は話そうと思ってたことが 結構出てるんですよね 何を話したかったかというと データソースレイヤーについてあの 話したかったんですよ で Poi DAだとデータソースというのがある意味ですというふうに言ってて コラチと時代を感じるんですけど マスラを追いといて これとやり取りするための アクティテクチャパターンというのが よっつあります これはエピソード1の これ複習になるんですけど 大きいには デーブルデータゲートへ ローデータゲートへ アクティブレコードデータマッパーと 4つがありますよっていうので 今も話しながり 出てきましたね トランザクションスクリプト の時は ローデータゲートへ もしくはこの本だ テーブルデータゲートへ ですね テーブルデータゲートへ とか ローデータゲートへ とやり取りしますよ と この話は多分さっき触れてなかったと思うんで 話すんですけど ドメインモデルを使うときに ワドゾムさっきをおっしゃってましたが そのドメインモデルの 状態とかを映像化しないとシステムとして なりたたな弱げですよね それをどういうふうに 映像化しますかっていうときに 多分2つの方があって 1つは先から出てる アクティブレコード これは ローデータゲートへの ドメインモジクも 速してドメインモデルとしても使えるし セーブってやったら その状態を保存できるみたいな 奴と あとデータマッパーですね これは僕の理解としては アクティブレコードって 結局その構造上を テーブルとドメインモデルが 1対1であるっていうものを の時じゃないと使えないんですよね なんですけど 1対1じゃないときも あります 様々な理由によって様々なっていうのは 例えば アットからりファクターに薄くるパターンとかあると思うんですよ テーブルの構造は変えられません なんかの理由で なんだけどドメインがすごい 負殺になってきました いう状態において テーブルとドメインモデルが 1対1になってたらこの表現できないと なので ドメインモデルは自分たちがこう 作りたいように作って それを引き数にして セーブとかによくと 後ろのテーブルに何個かのテーブルに 別れて ドメインモデルの続声とかが 保存されるみたいな そういうことをやりたいときに データマッパっていうのを 使うっていう 認識なんですけど なんかパーラーさん的には 聞いてて 伴いました 大体そんな感じというところで アクティブレコード選ぶか データマッパを選ぶか リレーションのデータベースの マッピングにおいて どちらのパターンを選ぶかっていうのは 正直ドメインモデルと テーブルの構造っていうのが どのくらい近いかによりませんね 完全イチしてるとか ものすごく近いんだったら アクティブレコード選ぶし 遠音だったら データマッパを選びますというような話です なんで遠いのかっていうのは 前向きの理由と 後ろ向きの理由があって 後ろ向きの理由っていうのは もうデータ構造は 変えられませんとか あるいは 既存のデータベースを使っていますとかね なるほど いいのは当然ありますよね ので 数既存のデータベースの 明明企画とか 構造とかが アクティブレコード向きではないとか 正常はありませんね あるし データベースのデータモデルより ドメイモデルの方が 複雑で構造も 登場人物も多い で それを データベースに対して どうやって 映像化していくかっていうと 一体一で映像化するのは 難しいし かつ理想的でもないので データモデルに対する マッピング自体は 専用のマッピングの仕組みを 設けて そっちに任せた方が いいんじゃないかっていうのが これが データマッパーの考え方です ただ それ以上に なんていうかな メンタルモデルとしてあるのは どっちが 主体化みたいな 同じなんだけど 主体 データマッパーパターンというのは オブジェクトを 映像不可視にいくんですよ オブジェクトが主体で それを 何てか リクエストレスポンスを マタイで 映像化したいとか ずっと ネモリジョンに させるわけには いかないから 仕方なく データベースに 試めと ふかというような話なんですよね で 試めと ふかっていうときに リレーショナー データベースが ファストチョイスになるから 仕方がないから データベースの 二次元表の 世界に マッピングして とっておきましょう というような話 だから オブジェクトを 映像不可するなんですよね それに対して 例えば アクティブレコードは それと対象になるのは リレーショナー データベースを バックエンドにして 効果的に ダメイン モデルを 作っていきたいと いう話なので アクティブレコードって レイルズの アクティブレコードは 特になんですけど SQLのDSLですよね SQLを 隱形してはいないですよね じゃなくてSQLを どうやって 効率的に 掛けるか というのを 試行しています だからSQLは あまり 隠す気ないですよね もう 名前で出ていちゃってますからね だからね なので どっちかって言うと だから データモデルと ダメインモデルは 結構近い あるいは 完全に 一つレベルで近い で その上で どうやって データモデルに対して 効率的に プログラミングを 行い で カツ そのロジック自体は データモデルに 書くのは 辛いから 手のアストアートブルシー者 ところに 書くのは ちゃくちゃ 辛いので そうじゃなくて クラスの方で その 行に関するつまり その アイデンティファイヤーで 認識される 行に 基づいたロジックに関しては 掛ける場所を マッピング対処の クラスの方に 用意しましょう だから ドメインロジック自体は プログラミング の方で 書きましょう というのが アクティブレコードのスタイフ というところかなと思う だから どっちかっていうと RGBが 主体で それに モデルとなる クラスは マッピングした いついとなっていて ロジックを 確保して みたいな そういうようなイメージですよね なるほど ちょっと 集中関係みたいな しても すごい 新しかったですね 僕の中で 確かに そうです 言われてみれば なるほど あと ここで そろそろアクティブレコードの話 で レイルズアクティブレコードの話に いけそうなんですけど 一個 多分 この話をする 前に触れておきたいのが 今までレイヤーの話と それから データソースの話 ドメインレイヤーと データソースの話をしてきたじゃないですか レイヤーっていう カンテン レイヤーの数っていう カンテンが見たときに アクティブレコードと それ以外で 違いがありますよね っていうのを 一応 来たくて 当たり前なんですけど アクティブレコードっていうのは さっき言ったとおりで ドメインモデルと モデータソースが もう 完全にくっついているので プログラムの 例やっていうのが 全部 暮らせて 定義されているとしたら 暮らす一個だけですよね その2つの例を表現するのに データソース例や ドメインで 屋が一つの暮らすに 入っているっていう話しいですか はい そうです そうです 例えばデータマッパーの パターンを使うのだと データマッパーで一つのクラスと ドメインモデルで 一つのクラスみたいな感じで 登場人物2つのように やりますよね クラスじゃなくてもいいんですけど クラスと 後それからレイヤーっていうのが ちゃんと1個1個 一体一で対応しているっていう 状態に なりますよね なんで ここでちょっとどのデータソースの アーキテクチャパターンの どのパターンを採用するかで ちょっと登場人物の数に探てますよ っていうのを ちょっとこれ触れておきたいんですよ 本題入る前に それでやっとエイレーズのアクティブクールの アーシー入るんですけど まずアクティブレコードっていうふうな 名前がついていることからも わかるように 現状のアクティブエコード パターンをちゃんと実装してますよね パターンとしてのアクティブレコードを 実装したオーローマッパーになっていますよね レイレーズのアクティブレコードは パターンとしてのアクティブレコードの実装になっています いや そうですよね ただそれ以外にも役割を持ってるというか ターンナルオーフマッパーではないと思っているんです 僕は どういうことかっていうと 先この本題に入る前に アクティブレコードパターンっていう のを実装すると ドメインレイヤーとデータソースのレイヤーっていうのが 一つのクラスにまとまりますよねっていう話をしたと思うんですけど さらにドメインレイヤーの時の話で ドメインレイヤーって2つに分かれることがあります ドメインモデルの上にサービスレイヤーとかを作って それを2つのレイヤー 分けるみたいな構成を多いんだけど これを分けなくて よいよみしてるなっていうふうに思っているんですよ レイレーズアクティブレコード 具体的にはどうやってやってるかっていうと まずドメインモデルとしての役割っていうのは このアクティブレコード バイスっていうその あの キテイクラスがあるんですけど レイレーズのアクティブレコードの これを掲昇する形でモデルを定義するんですが このモデルクラスの 印刷するとっていうのが これはドメインモデルとしての ドメインモデルレイヤーのことを 書く話なんですよ なんですけど そのドメインモデルレイヤーの中の もう1個を触りしてレイヤーのも っていうののやつっていうのは これ何やるところかっていうと また例えばその バリデーションしたりとか あとそれから ドメインモデルを使って書き取りを組み立てないみたいなのをすると思うんですけど それっていうのは レイレーズはバリデーションっていう DSLってあったりとかコールバックっていう DSL これでやっぱりレイレーズのモデルの中に おかけるようにしちゃってるんですよね なので 僕は何を頂かったかっていうと パウラーの言ってた 3つのレイヤーのドメインレイヤーの中 まあさらに2つに分かれるんで 4つって言ってもいいかもしれないんだけど そのうちの プレゼンテーションレイヤーにお見つく 大陸にはサービスレイヤーと ドメインモデルとそれからデータスをするレイヤーで これを全部アクティフェクトっていう レイズは これをアクティフェクトっていう形で 一つのクラスの中にかけるように ししまった っていうのがこれがレイルスのアクティブレコードの 招待にあるというふうに僕は思っているんですよ あとこれだけだとレイヤーを足くしただけなので 生産性っていうところにはまだちょっともう1個足りないかなっていうふうに思うんですけど ここでDH1すごいところは確かレイルス1.2だったと思うんですけど リソースベースのルーティングっていうのを言えましたと そうですね これでURL上のパスマカに含まれるURLで表現されるリソースっていうのとモデルを1対1で対応させたんですよね でレストフルの考え方に乗っとってリソースに対するHTTPのメソッドによる操作っていうのをモデルのクラット操作に対応させましたと そうすると何ができるかっていうと そういうルールになるんでスキャフォールドっていうのがあるんですけど レイキュースシエルアイでそれをたたくと そのルールに乗ったアクティブレイコードがカバーしてないプレゼンシュン あっすいませんこれ 多分ねプレゼンシュンっていうとビューのことで使っていうふうになると思うんですけど プレゼンシュンネイヤーってそのウェブのプレゼンシュンの話なのでペイルスで言うテンプレートビューと あとそれからコントローラーっていうのをここで言うプレゼンシュン装扱なんですけど 残りのプレゼンシュンっていうのはスキャフォールドといっかってこう 買ってにできるようになっちゃったんですよ なんでレイルセンジニアがやることって 規矩なにかっていうとまずデータモデリングしますと これは前回のイキスをどう産書してくださいと それやったらまあ たまに例外もあるんですけどだいたいその その時に出てきたデータモデルっていうのが URLのリソースにそのワンマッキーにできますと そしたらその名前でスキャフォールドを叩いて それででき上がったコードの さっき言ったミツエスイースペースをと バリテーションと コールバックにそのアプリテーションにこういうのロジック ドミロジックを書いたらこれアプリテーションが完成してしまうっていう こういうワクグミを作ったというふうに僕は思ってるんですよ でこの今言った僕のワクグミっていうのが たぶんレイルズの生産性の あの招待だとえーいうふうに思ってるんですけど なんかすいません僕はバーって喋ってたんですけどパンさんよーの端式ってどう思いました この当山が考えをまとめながら 喋ってるっていうのをよくわかる感じででもいいんですけど レイルズは生産性の招待ってあの生産生産性 生産性っていうとまたいろいろ難しくなるけど コードを 各量が少なければ少ないほど生産性は上がりますよねという前提にある程度立ってますよね プログラミング言語には一業あったりの表現力っていうのが 多い言語もあれば少ない言語もあるんだけど 人間がかけるコードというのは表現力の多い少ないにかからずある程度の範囲に収まるということが言われています てなったらその少ないコードでより多くのことができる方がいいしさらに言えばコードを書く 使用性が少なければ少ないほどより生産性は高いということにつながっていくわけですよねで レイルザーだからどっちかっていうとそのアキテクチャーにレイルゾーでやつを引いたんだけどそのレイルゾーでレイルゾーっていうのは つまり多くのものがクラッドリソースのクラッドで示すことができるというような医師の強い家庭ですよねでリソースのっていうのはつまり ウェブのリソースつまりレストフルな設計というのが外側からのクラッドで データベースのインサートとかアップデートとかデータとかそれがデータソースがあのクラッド この2つのクラッドというものをちゃんと設計すると考えることが要に減りますよ あ考えるっちゃな 隠べきコードが要に減りますよっていうのはこれがレイルゾーの世界ですから前回ローコードだって言ったんですよね ローコードだってのはつまりDHJのすごかったのは良い設計に寄せていくと隠べきコードを減るような感じになってんですよね これがとても面白いところでつまり良いデータベース設計をします インギタブデータモデルとかも含めたその基地にと物語を事実を確診できるような設計を意識して設計して で初そこからだけをして物理設計していきますみたいなところと リソースモデイングでとURのレストフのURモデリングというのをキッチリやっていくとそれによって ポジションななにか誰がどういうのも間で何をするべきかというのが基本的にそっからバーっと決まっていくんですよね そうすることによってそのデータベース側の設計が定まればモデルのレイヤーとかが決まっていくし URL側の設計が決まっていくはプレゼンテーション側のレイヤーが決まっていきます しかもちゃんと設計していくとその2つっていうのはまあまあ近くなると で完全に一指してしまうとそれは5回になっちゃって レイルずーとはデータベースのクラッドをウェブに公開することであるという無茶苦茶な5回があるんだけど そうなると何があるかっていうとレストフルのウェブサービスさん何がひどいって N+1のコールがたくさん発生するみたいなどい5回が発生するわけですね だからなんかテーブルレベルのクラッドをウェブに公開するってなると ひどい設計がまれのでそれは全然違うんだけど でもレストフルなリソースの2体するやり取りをコントローラーに1位にマッピングできます でそこからコントローラーが何をするかっていうのはそのモデル側のやり取りとはアクティブレコードを回して マッピングできますというのがあるのでやっぱり考えることは少ないんですよね で僕の意見としては スキャフフォードでバンとレール1つの日にしてしまうと データベースのクラッドウェブに公開することになっちゃうので まあそれやめろって話なんだけど それはそうとしてだから僕は考えたんどっちかというと2つの設計データベースの設計と URの設計でハサミウチにするみたいなイメージ 両方からこうターンを走ってそれで満たなで調整するみたいな だからそれが完全に1体1になっちゃうと 間違ったレストフルなイメージの設計ができてしまうから それはやりたくないんだけど ウェブの設計の方をちゃんとレストフルなURのリソース設計の方をちゃんとやれば これでコントローラが定まりますよねそれによってハサミウチすることができるので 僕自身は考えることがやっぱりすごく減るんですよ というか2つ設計すればあとは行動書いていくだけ 定められたところに行動書いていくだけみたいなモードになって しかもデータベース側でイベント事実を失わないようなイベントに着目した設計ができていれば レストフルなウェブのサービスの方もそういうその第三の リソースとリソースとの関係性を示すURの設計というのに対するヒントになるので そうするとそのレストフルなウェブの方も どうしじゃなくて明智の世界ですよね あのどう知ってゲットポストプットデリートしかないからパッチマルけど だからあのレストフルなウェブサービスの方は明智の世界ですと でデータベースの方も基本的に明智の世界ですその明智にリソースといつての明智とイベントとしての明智があります だからそれらをマッピングしていくと結果的にはその事実を捉えるという設計の観点において その事実はウェブが枯れやってきてデータベースに拓農されますという一つの日のレイルが作れるんですよ 周り回って そうするとこれが真のレイルじゃんって話になるのねレイルズの なるほど だからリソースのレイルズのクラッドをとしてのレイルズだけの目を見てしまうと レイルズはデータベースの設計を一体一でウェブに公開する場下のフレンワークだって話になっちゃうんだけどそうじゃなくて リソースのクラッドとイベントのフリエートのシーがあって そのイベントの設計というのをちゃんと捉えていけばそのイベントのレイルがあるんだよって話ね そっかじゃあ僕の今の理解をちょっと話すとやることは二つあって一つはこの前のエピソードも話したイベントをデータモデルを作るっていうことでもう一つは そういうの関係なくウェブのシステムとして何をクライアント側にインターフェストして亡定するかこれが言われるってかリソースの設計になると思うんですけど っていうことを考えますそうですねそうするとまず全社の方からはモデルができるじゃないですかデータモデルに でこうしたの方からはそこを起点にしてスキャフォールドでコントローラーのことができますとそのコントローラー中でリソースとデータモデルのデータモデルがもし対応するんだったらもう本当に一番速い 言うとで対応したかったとしてもそこをちょっとこによってやったらもうそれで終わりっていうそういう設計の進め方すると早いこれがレイルズンひたレイルなんじゃないかっていうふうに思ってるっていうのがわたさんの視聴ってことですかねそうですね 一体一であるって考えちゃうと データベースのテーブルの数とレイルズの言われ公開する言われのリソースの数が完全一つるみたいななしになっちゃうんですがなりますねそうですよね全然そんなことないでしょそんなことないで全然そんなことないで どっちが多い少ないって話じゃなくてデータベースの方の大3時正規かあるいはそれ以降の正規かの姿とレイルズが公開するレストフルなURLっていうのは一しないですよねもし 大3時正規系のテーブルを全部公開するとしたら今度は細かすすぎるものも当然含まれてくるという話になりますよね もでそれそんな話じゃないよ楽しい になるわけだからデータベース設計側でG-Zのモデイングして で第3時正非が以降にしていくことがそのままURLと で公開されるかっていうとそうじゃないのででもレイルスのスキャフォールドが そういうとても強いバイアスをURL設計にあたえちゃったんですよね結果的にね ってなるとレストフルのウェブの設計ってテーブルレベルのクラッドをURLに公開することであるという ひどい誤解が広まってしまって結果的にレストフルなバックエンドのサービスに対してやり取りするためには クライアント側からN+1のゲットとかポストとかプッドとかやんなきゃいけないみたいな ひどい設計がいの中にいっぱい出ましたよね そうそうでしかもちょっとよくないのがグラフキュエルの生徒性を説明するときにその例が使われるんですよね そうそうそうそれがひどい話でね そうじゃなくてそうじゃなくて君のレストフルな設計は誤っているって話なんだけど これが強い誤解として広まってしまった原因を作ったのはレイルズだと思ってます いやそうなんですよねだからちょっと話しておりますけどグラフキュエルとグラフキュエルがどこは忘れてるかというと そのN+1とかそういう話じゃなくてコントロール権なんですよね結局 そうですよN+1クエリーを作らないっていうか公開スインターフェスがうまく工夫されていればそもそも N+1問題と起きないんですよねレストでもそれを叩いたら全部書いてくるんでただそれをクライアントサイドと サーバサイドで分量するってなったときに何か作るときにそのクライアントサイドの すごうこういうのを作りたいんだよねっていうのを作るときにサーバサイドいじらないで気が上がっちゃうじゃないですか でそうするとうまく生産せたくできないからクライアントサイドの要求っていうのはそのクライアントサイドで実装が関係するようにするためにはどうせ はいいですかねっていう話になってきてでじゃあサーバサイドがあれそれの要素になるようなものは公開してるんでそれを組み合わせて 君たちの欲しいクイリーを作ってくださいとっていうのがそれがグラフキュエルの僕が優れてるところだと思うんですよ そうですなんでそこに隠したいですよねじゃないと実装点として謝った頃からスタートするということになってしまいますよね だからなんかレストフルなエピアイツライですってじゃなくてそれそのレフトフルな設計がひつらいんだよそれだいぶ謝ってるよねって話になってしまうので それはアンフェアだって話なんだけど今行った通りグラフキュエルの本質っていうのは本当に欲しいもの知ってるのはクライアントサイドであると でだけど欲しいものをもらうためにサーバーサイドと分業しなければならないあるいはやり取るしなければならないのであれば 当然本質的にはそれで必要なアジリティが失われませんねって話しないませんね だからグラフキュエルとかあるいはグラフキュエルだけじゃなくてもそのクライアント側からスキーマーを提示してで データを持ってくるやり方の本質っていうのはアジリティを手に入れるためですよね それは本当に必要なものを知っているのはデマンドサイドクライアントサイドだしさらに言えば 試行作合をしたいのだから 稼説検証を回せるためのアーキテクチャーが必要ですよねっていう話ですねだから何が正しいからこれを作って下さいってじゃなくて何が正しいかわからんけど色々 やってみたいだからデマンドサイドでクライアントサイドでデータがじゃあ情報がな情報が必要な サイドの方で色々試行作をしてクエリーできるような仕組みができれば何ができるかっていうとチームの特徴性ができましたよねでデプロエの特徴性もできる って話これこそが大事なところじゃないですかデプロエのアジリティが大事じゃないですかって話になるだから エネルプラスイスト全然関係なきゃねっていう話になるんでねそうなんですよはい しかしクラフキルエルの話はたくすぐになかったんですけどさぁちょっとそうですねもう一個僕は実は話したかったことがあるんですけど それはまあ最初をもう時間あるもんやるっていうことで一旦思い出を言って僕はあの今回のマストや話したかった あのレイルズアクティブレコードってたんだろう終わるまっぱじゃないよっていうのはこれで一応全部話したかなと思うんで だったんあのちょっとここで閉めたいなというふうに思いますたんなるホールマッパじゃないよっていうのはたんがろう アルマッパだったらアクティブレコードの実装として閉じているはずだけどそうじゃなくてレイルズの ジェネレートモデルとかで出てくるやつはバリデーションもあるしコールバックもあるし なので言われるリックエストレスポンスに基づいたそのアプリケーションこういうのロジックを書く場所でもあるし データベースのやり取りを書く場所でもあるしドメインロジックを書く場所でもあるよねだから 3つが1個に入ってるよねって話をしたってことですよねまとめていたいであるようですそうです 本来はアプリケーションサービスとドメインサービスとデータマッパみたいな感じで 分かれてるやつがそうじゃないや一個だけうみたいな感じでアプリケーションサービスもドメインサービスもドメインロジックもデータとのマッピングも全部一 クラスに入ったそれによって数を減らすことによって高い生産性を発揮しているんだってのがこれが もとのアクティブレコードてパターン目を超えたレイルズのアクティブレコードというオーローマッパーの招待であるというようなところですねすごいあの綺麗な権ご顔してもらってありがとうございますその通りです じゃあ今の電話区は止まったと思うんでちょっといつもの最後終わるのをやると思うんですけどはいポッとキャストに関するご意見ご覧頌は明日グテクスタイフ夢におやすくださり申ししております それでは私は本日はありがとうございましたはいありがとうございました はいっせーしまーす