1. London Tech Talk
  2. イベントソーシング・フレーム..
2024-07-27 1:26:14

イベントソーシング・フレームワークの開発秘話 (Tomohisa, Kawae)

spotify apple_podcasts

Tomohisa さんと Kawae さんをゲストにお呼びしました。イベントソーシングの C# フレームワークである Sekiban について、なぜ開発したのか、なぜオープンソースとして公開したのか、どのような技術と知恵・工夫で支えられているのか、どのような試行錯誤があったのかについて詳しくお話を伺いました。

Tomohisa さんがメインでコードを書き、Kawae さんがブルペンピッチャーのような立ち位置、もしくはコーチと選手のような協力体制を敷いているとのこと。実際のプロジェクトに Sekiban を導入する中で発見した機能提案や要望を早いサイクルでフィードバックすることで、継続的なフレームワークの改善を達成しているということでした。

フレームワークを開発するに至ったストーリーでは、大規模分散システムをドメイン駆動設計で実装する際に当たった壁を、イベントソーシングで乗り越えた経験と共に紹介していただきました。C# を採用した理由から、C# を用いた開発一般やプログラミング言語 Delphi についても言及しました。イベントソーシングが適したアプリケーションの要件から、関数型への想いについても触れました。

Sekiban という命名の背景や、その他の候補についても気になる方は、ぜひエピソードを聞いてみてください。

ご感想はご意見は X でハッシュタグ ⁠⁠#LondonTechTalk⁠⁠ をつけてつぶやいてください。お便りはこちらの ⁠⁠⁠Google Form⁠⁠⁠ でも募集しています。

サマリー

本日のメインのトピックは、イベントソーシングのフレームワーク「石板」の開発について、トモヒサさんと富士山さんがお話しになります。イベントソーシング・フレームワークの開発秘話では、石板開発に至る経緯や石板開発の目的やモチベーションについてお話ししています。石板フレームワークの開発秘話では、Cシャープ、データベース、イベントソーシングなどについて詳しく語られています。イベントソーシング・フレームワークの開発秘話や関数型プログラミングによる書き方の変化について話し合われています。イベントソーシングを通じた開発の安心感やプログラミングの制限についても話し合われます。また、イベントソーシングの広まりに関するアイデアも探求されます。イベントソーシングの開発秘話についてもお話しになります。石板というフレームワークの開発において、コーディングと考えるタイプの2人の開発者がお互いの良い点を組み合わせて素晴らしいチームワークを発揮されました。

石板の開発の背景
Kazunari Okuda
London Tech Talkリスナーの皆さま、こんにちは、Kazuです。
本日はですね、2人のゲストをお呼びしています。
1名はTomohisaさん、もう1人はKawaeさんです。
お二人、よろしくお願いします。
Takashi Kawae
よろしくお願いします。
よろしくお願いします。
Kazunari Okuda
本日はですね、お二人が開発に携わっているSekibanというOSSの
イベントソーシングのフレームワークを開発されたということで
そちらのお話を聞かせていただくために、お二人をご紹介しています。
まず最初は、お二人がどういう方なのかというのを
軽く自己紹介をお願いしてよろしいでしょうか。
Tomohisa Takaoka
はい、じゃあ僕から自己紹介を始めたいと思います。
おかおか、Tomohisaといいます。
株式会社Jtech JapanでCTOとして働いています。
London Tech Talkは過去3回ぐらい出させていただいたので
聞いて覚えている方もいるかもしれません。
DDIAの輪読会から入って、2冊目のトレードオフの本も読ませていただいて
今、3冊目の輪読会にも参加させていただいています。
今日は技術の発信・ナッシュができるのを楽しみにしています。
よろしくお願いします。
Kazunari Okuda
よろしくお願いします。
Takashi Kawae
私は川江隆といいます。
同じく株式会社Jtech Japanでソフトウェア、主にアプリケーションの開発の
エンジニアの方をさせていただいています。
基本的にはバックエンドと呼ばれる、そちらの方の領域を手掛けることが多いし
自分でもそちらを書くことが好きなんですけれども
フロントエンドの方も書くという感じで
幅広くいろいろな会社の中のアプリケーション開発、いろいろな分野に
携わっています。
石板の開発にも高岡さんと一緒にいくらか関わらせていただいていますので
今日参加させていただいています。
今日も技術、そうした技術の話しできるのを楽しみにしています。
よろしくお願いします。
Kazunari Okuda
よろしくお願いします。
お二人は、ブッククラブの方は参加していただいて
富士山さんの方は川江さんの方は完全に初めてということで
この本編の方は初めてですよね。
Takashi Kawae
そうですね。初めて。
聞かせていただいている回はたくさんあるんですけれども
参加させていただくのは本当に初めてです。
Kazunari Okuda
よかったですね。
今日は日本から、普段はお二人とも
ちょっと石板の話とはずれるんですけど
普段はどこから働いていらっしゃるんでしたっけ?
富士山さんはアメリカの西海岸の方?
Tomohisa Takaoka
そうですね。僕はカリフォルニアのロングビーチというところで
最近言う場所の説明は
エンジェルスタジアムとドジャースタジアムの中間あたりにある町という感じで紹介しています。
Kazunari Okuda
それは大谷公家ですか?
Tomohisa Takaoka
そうですね。大谷公家はやっぱりすごくて
アメリカ人の方でも知らない方多かったんですけれども
最近は結構知っている人が増えてきたので
かなり有名になってきているという感じがしますね。
Kazunari Okuda
なるほど。
河合さんは普段はどこから働いていらっしゃるんですか?
Takashi Kawae
そうですね。私は今は日本で働いています。
以前海外に行ったこともあったんですけれども
もうしばらく日本に戻ってきて
今はずっと日本で働いているという感じですね。
Kazunari Okuda
今回はお仕事の関係で
トモヒサさんは日本に戻ってきていらっしゃるということですね。
Tomohisa Takaoka
時間調整がちょっとしやすくなって良かったです。
Kazunari Okuda
そうですね。私も今の会社は
私もベルリンの方で働いているんですけど
本社がニューヨークなんで
ニューヨークとベルリンで時差があって
ニューヨークとベルリンなら
ベルリンのお昼の時間が過ぎてから
ニューヨークの人たちが起きてくる感じで
一応被っている時間があるので結構働きやすい
その時間で働きやすいというのはあるんですけど
お二人の場合はどうですか?
日本と西海岸の方だと
Tomohisa Takaoka
西海岸は逆に東海岸だったら
仕事時間が完全に交わらないという感じなんですけれども
私のいる西海岸は
私の夕方4時とか5時とかに
日本が9時になるので
4時から6時、7時ぐらいまでが一番
ミーティングもしやすい時間という感じになります。
Kazunari Okuda
なるほどですね。
朝は集中して
ミーティングがない状態でみたいな感じですよね。
Tomohisa Takaoka
それができるのは結構いいですね。
Kazunari Okuda
私もそれは結構感じてます。朝。
全然ミーティングは入ってないんで。
Tomohisa Takaoka
少ないんですか?ベルリン側の人たちっていうのは。
Kazunari Okuda
いや、半分ぐらい
開発者の半分ぐらいはいるかもしれないですね。
人数的には。
まあニューヨークが中心で
あとは東海岸の方に
ニューヨークじゃないところに
他のエンジニアもパラパラといる感じですかね。
Tomohisa Takaoka
結構国際開発が標準というか
いろんな会社で採用されて
結構何か技術で解決できても
時間だけはちょっと解決できないというのは
Kazunari Okuda
そうですね。
本当にそうだと思います。
時間だけはどうしても解決できないですよね。
Tomohisa Takaoka
眠さは変えられませんからね。
Kazunari Okuda
そうですね。
って感じでスモールトークだったんですが
本日のメインのトピックは石板ということで
OSS、イベントソーシングのフレームワークの
石板の開発について
お話を聞こうということでした。
まず石板とは何ぞやというのを
軽くご紹介いただければと思います。
了解です。
石板というのが私たちイゼテックジャパンが
Tomohisa Takaoka
作ってオープンソースで
GitHubに公開している
フレームワークを
アプリケーションフレームワーク
というものになります。
Cシャープで書かれていて
イベントソーシングという技術を
採用していて
イベントソーシングというのは
このロンドンテックトークでは結構話題になっているので
聞いている方は知っている人が多いかもしれないですけれども
イベントを追記追記で
書いていく。
それで現在のステートを保存するんじゃなくて
新しく変わった出来事を保存することによって
歴史をたどってみれば
現在の状況も分かるので
その現在の情報については保存しないという
そういうやり方をするんですけれども
イベントソーシングっていうのが
実際書くと結構大変で
これをそのイベントの順番を直したりとか
たくさんイベントが出来過ぎた時に
スナップショットを取らなきゃいけなかったりとか
いろいろ面倒なことが増えてくるので
面倒なことは普段の開発している時には
考えたくないから
石板というフレームワークに任せてしまって
そして書けるように
出来るだけ
簡単に書けるようにしましょうということで
最初は社内向けに作ってたんですけれども
せっかく今の時代なので
オープンソースで公開しようということになって
公開したのが
2023年の12月なので
半年前ぐらいになります
開発自体は大体もう2年ぐらい
開発をしている感じになりますね
Kazunari Okuda
長いですね
実際に
社内のシステムで
実際に使われているということですかね
Tomohisa Takaoka
そうですね
私たち自宅開発が主な仕事であるんですけれども
顧客向けのシステムに
大体4つか5つぐらい
入っていて
それにも1つ2つ3つぐらいでしょうかね
なので結構使われ始めているという状況です
Kazunari Okuda
いいですね
自分の
必要と思うものから
それを導入してどんどん
フレームワーク自体を改良していって
オープンソースに公開するって
王道のルートというか
そうしないとなかなかフレームワークとかの
アップデートって大変じゃないですか
かつ自分の入れたいものとかがないと
石板の特徴と利用方法
Kazunari Okuda
なかなか公開してそれで終わっちゃったり
とかいうことが結構ありますよね
Tomohisa Takaoka
そうですね
やっぱり最初は難しそうなので
他の既に出ているフレームワークを
使ったほうがいいのか
それとも自分たちで作ったほうがいいのか
みたいなそういう悩みもあったんですけれども
自分たちが
本当に好きなようにというか
本当に私たちで
考えて一番ベストと思う形に
今できているので
自分たちで開発してよかったなと思っています
なのでオープンソースで公開しているといっても
まだね
すごいたくさんに使われているわけではなくて
主に自分たちの開発を効率化するために
オープンソースを運用している
みたいなところがあります
Kazunari Okuda
なるほど
河合さんもこの開発には最初から
携わっていたお二人で
このフレームワークを作ろうと
多分議論があって
作るか作るか既存のものを使うか
多分議論があって
そこからよしじゃあ開発していこうというのは
何名か社内のエンジニアの方が
携わったということですよね
Takashi Kawae
そうですね
実質的に携わったというか
一番最初から今に至るまで関わっているのは
二人だけっていう
しかも
ソースコードを書いているのはほとんど
実はトモヒサさん
お一人なんですね
ただ私は一番石板が出来上がる前から
流れとしてずっと関わっていて
どっちかというと私の役割は
野球でいうブルペンキャプチャーみたいな
ピッチャーのキャッチボールの相手みたいな
そういう感じなんですね
トモヒサさんと私と
ずっといろんな開発の効率化っていうんでしょうか
もっと良い開発できるにはどうしたらいいか
みたいな話をずっとしていく中で
自然に石板が出来上がっていく
その仕様を決めたりとか
一部私が書いたコードを反映していただいたりとか
仕様を考えたり方向性を決めたりっていう中で
ずっと関わらせていただいている
そんな役割をですね
Kazunari Okuda
なるほど
ブルペンピッチャーっていうのめっちゃ
大谷の話から
すごい面白い例えですね
しかも分かりやすいという
なるほどですね
少ないですが書いてはいるんですけど
どういうフレームワークを作っていくかっていうのを
ピッチャーとキャッチャーのように
今回はこの給紙で行こうかみたいな感じで
話し合って
コミュニケーションとって
Takashi Kawae
決めていったという感じですか
そうですね だからもっと言うと
私が欲しい機能とか
こうして欲しいみたいなリクエストも
かなり盛り込んでいただいているっていう
ある種この石板というフレームワークの
一番のファンみたいな
自分がこうしたいっていう
こうして欲しいみたいな機能を
話し合う中で
それも題材にして
実際にその中に反映
していただいている
実際私も自分で社内の担当しているアプリケーションに
石板を使っていて
自分のプロジェクトでも使うし
そのフィードバックも取り込んでいただくし
そしてその石板を実際に使ってみて
本当にこれはいいフレームワークだなみたいな
トモヒサさんと富士山さんの役割と石板のフィードバック
Takashi Kawae
自分で自分じゃないんですけど
自分たちで満足しているみたいな
Kazunari Okuda
素晴らしいですね
トモヒサさんは
アプリケーションコードは書くんですか
CTOとおっしゃっていたんで
石板を使って
実際にアプリケーションを書くこともあるんですか
Kawaiさんの方はバックエンドエンジニアとおっしゃっていたんで
これを導入して
開発を進めていく
どっちかというとユーザー側で
フィードバックをどんどん
石板に
フィードバックを与えていくという感じでしょうけど
トモヒサさん自身もこのフレームワークを使って開発することはありますか
Tomohisa Takaoka
そうですね 実は結構あって
私たち小さい会社なので
いろんなお客さんから
あれが欲しい これが欲しいみたいなのがあった時に
結構
難しい目の案件とか新しい技術の案件というのは
僕を通っていくんですけれども
その時にAIで
分析をするプログラムを
サンプルで作りたい
みたいなことになったら
僕が最初の数週間ぐらい
カードを書いて
それを他のエンジニアに
託していくみたいな感じで
結構そういう感じでコードを書くこともありますし
今やっているのは
石板をせっかく
自分たちがいいと思っているので
開発秘話の始まり
Tomohisa Takaoka
普及させたいみたいなのがあって
普及のために今度はオープンソースで
アプリケーションを書くみたいなのもやっていて
まだ全然機能が足りないんですけれども
出体金システムみたいなのを
前に作ったことがあるので
それを石板で作ってみよう
みたいな感じで
僕の場合はアプリケーションを書きながら
フレームワークを調整していくみたいな感じです
Kazunari Okuda
なるほど
そうすると
開発はどんどん石板に対して
アップデートしていくモチベーションは
どんどん上がっていきますよね
Tomohisa Takaoka
精のループというか
そうですね
最初の方は
石板の初期の頃は
フレームワークがおかしくて
問題になった
だいたい見つかるんですけれども
フレームワークのせいで思った通りにいかなかった
結構あったんですけれども
最近だと問題が起きましたと言われて
フレームワークのせいかもしれないと思って
いろいろ調べた結果
結局使い方のせいだったということの方が
結構多くなってきていて
フレームワークの信頼性が上がっているし
フレームワークの問題が見つかったら
嬉しいみたいな
ここがまだキャッチできてなかったか
みたいなのがやっぱり見つかるので
そういうのがあったら逆に
嬉しく感じる感じになりました
Kazunari Okuda
なるほど
Tomohisa Takaoka
それは面白いですね
Kazunari Okuda
まだ完成してなかったのかみたいな
Takashi Kawae
実際自分たちで使って
それを使ってコードを書いていくので
もともとのスタートが
効率よくソースを書きたいっていうプラス
きれいに書きたいっていうのもすごい
一つの動機としてですね
モチベーションとしてあって
実際石板を使ってアプリケーションを書き始めて
きれいになったなと思いながら
まだどこかいろんなところに違和感が残ってるっていう
開発のモチベーション
Takashi Kawae
あるんですねやっぱり
それをどんどんどんどんその違和感を
ちょっとずつきれいになると
部屋の掃除じゃないんですけど始めるともっときれいにしたいっていう
どんどんきれいにしていくっていう感じで
かなりそれはモチベーションだったんじゃないかなっていう風に
今考えると思いますね
それでいうとつい最近もそんな感じでかなり大型のアップデートを
やってるんですけど本当にもっともっときれいに効率よく書きたい
っていうそういうモチベーションもあって
ずっと機能が追加されたりあるいはもっと
良くなったりしてるっていうところはあると思います
Kazunari Okuda
なるほど
その石板開発に至る経緯っていうのと
結構関わってくるような気がしてて
Zenという
公開されてる記事でしたっけ
Tomohisa Takaoka
はい公開記事です
Kazunari Okuda
最初の方で石板開発に至る経緯
ということが書かれているんですよね
複雑さに対応するアーキテクチャの必要性ということで
最初はMVCの開発から
DDD
ドメイン駆動設計
忘れちゃったやん
日本のドメイン駆動設計
ドメイン駆動設計から
CQRS
イベント創始
ところまで
何か自分は
トモヒサさんたちの中で
必要性というか
その中で生まれてきたのが石板
そこの流れを
Tomohisa Takaoka
ご紹介いただいてもいいですか
私たちもDDDというのが
会社のメンバーが
新しいもの好きのメンバーが
導入して結構それを全社的に
導入したのが2018年とか17年とかで
それを用いて開発してきたんですけれども
DDTによる
サンプルコードみたいなのが
結構いろんなところにあって
それは一応全体的には
レイヤードアーキテクチャ
クリーンアーキテクチャであったり
オニオンアーキテクチャであったり
レイヤーでそうであって
ドメインという部分には
そういう書き方が主な書き方であるんですけれども
それで一つのプロジェクト
結構大きめのプロジェクトを開発して
テストがしやすくなったので
これは良かったということになったんですけれども
ただ振り返りみたいなのをしてみると
ドメイン駆動設計にしても
解決されない問題みたいなのが結構あって
その一つ僕が
一つ気になっていたのは
トランザクションが結構
DDDだからってことはないんですけれども
SQ
リレーショナルデータベースを使って
データを保存するときにどうしても
大量のデータを一緒に保存しようとしたときに
トランザクションエラーになって
データがうまく保存できなくて
それをリトライするまで待っていると
お客さんが気づかなかったりとか
データがなくなったように見えたりとか
そういうのが結構問題が出ていて
それは多分一つ
私たちがまだ
大規模分散システムを作っていなくて
シングルデータベースでやっていたというのが
原因ではあるんですけれども
それをいろいろ解決する方法がないかなと思って
調べていて出てきたのが
追記追記で
やるイベント送信具っていうので
理論的に考えてみると
これだと結構な問題が
シンプルになるなと思って
僕の方ではやり始めた
川上さんにも別のモチベーションみたいなのが
Takashi Kawae
あったと思うんですけどどうでしょうか
そうですね
流れとしては今友人さんが言ってくださった
社内でDDDにいろいろ取り組んでいて
割と大きめのプロジェクトでも
考え方はアーキテクチャに基づいて
アプリケーションを書いて
良い部分と
いいんだけどもうちょっとなんとかならないかなっていう
そういう気づきみたいな発見みたいなものが
溜まっていったそれをなんとか解消できないかな
っていうところがやっぱりモチベーションだったと思うんですね
それはDDDだけではなくて
自分たちがずっと開発に携わってきて
長年いろいろ感じている疑問
自分たちだけではなくて世界中のソフトウェアエンジニアの人たちが
いろいろ考えてはいろいろな解決方法を
提唱していく共通した
そういう部分ってあったと思うんです
その中ですごく私が
なんとかならないかなと思っていた
ポイントたくさんあるんですけれども
一つには今言っていただいたレイヤーに分けるという
考え方
とても良いと思いますし合理的で
実際そういう部分たくさんあるんですけど
DDDでいういわゆるビジネスロジックを集中させるドメインという
そこはきれいになったと
そしてその前後のところはインターフェースで抽象化して
そしてドメインの中は非常にクリーンにきれいにできます
でもじゃあその前後は
っていうところが私はすごく引っかかったんですね
結局のところは例えばドメインの下に来る
リポジトリのところでインターフェースで抽象化することによって
ドメインはきれいになるけれども
でもインターフェースは実際動くわけではないので
実装を与えてあげなければいけない
それをリポジトリのレイヤーで実装していくわけですけれど
そこの実装に関しては結局
今までと変わってないんじゃないかな
実際変わってない部分ってあると思うんです
もちろんそれは実装するエンジニアの力量にも
関わってくる部分ですし設計とも関わってくる部分ですけれども
でもそれはドメインから追い出されただけで
石板の効果
Takashi Kawae
実際のところは
いろいろリポジトリを
データベースとデータをやり取りする映像化するという
その処理の中でやっていかなきゃいけない
いろいろな煩雑な部分そこは解決されてない
そんな風に感じたんですね
言ってしまえば部屋の中の部屋はきれいに片付いた
でもそれを押し入れに持っていっただけみたいな
ちょっとそういうところが自分の中にはあって
もっと全体的にきれいにならないのかなっていうのがすごくあったんです
やはりそのレイヤーに分けることで
もう一つ個人的に何とかしたいなと思ったのは
どうしても分けてしまうので
そのレイヤー間でデータを受け渡した時に
例えばDTO データトランスファーオブジェクトを使う
よく知られていることで
結局その実装がどんどん大きくなって
複雑になるわけではないんですけれども
ちょっと書かなければいけないものが
すごくたくさんになってしまう
それはきれいでシンプルなコードと
少し逆行するっていうか
入れない部分を感じたんですね
もっとそういうところもシンプルにならないだろうか
もっとこういうコードはここに置けば
もうそれだけで全部に
ところに回っていってくれるというような
同じようなコードをいろんなレイヤーに書いていかなくても
もう一箇所にそこだけ書けばなんとかなる
そういうような書き方はないだろうか
ということをちょうど友人さんが
いろいろ考えておられるのと同じ時期に私も考えていて
それで2人で話している中で
イベントソーシングというCQRSを使うと
全部とは言わないまでもかなりスッキリするんじゃないか
というところに気づき始めたというのが
かなり最初の段階かなと思いますね
Kazunari Okuda
なるほどですね
いいですね
いいというのは
やっぱり書いていくうちに
いろんな
もっと綺麗にできないかなとか
もっと効率的に書けないかなという部分は
私も開発者として結構あって
私はバックエンドエンジニアで
フレームワークのレイルズ
ルミオンレイルズというのを使っているんですけど
そうですね
複数人で書いていたりすると
もっと標準化できると
迷いがなく
他の人とも書けたり
できないのかなとかって
迷いって結構難しくて
上級者の方であればある程度
統一した見解っていうか
そういうのは
上級者であればあるほどそこにこだわりとか出てきて
どこに置くかっていうのは
議論が分かれるところなんですけど
でもフレームワークみたいに決まりがない状態とかだと
初心者とか中級者の方っていうのは
どこに何を書いたらいいのか分からないとか
っていうのは結構出てきてて
そういう部分が結構フレームワークが
助けてくれるところかなと思っているんですよね
だからフレームワークを
自分たちで
綺麗なコードを書けて
みんなが理解しやすくて
こう書けばいいんだっていう
道筋があるフレームワークを作っていくっていうのは
結構メイクセンスというか
ことですよねと思いましたね
Tomohisa Takaoka
やっぱり上級者で
みんなが上級者だったらいいです
上級者の中でも結構好き嫌いみたいな
このやり方は
この人は好きだけれども
このやり方はこの人はあんまり好きじゃないみたいな
そういうのでやっぱりいろんな書き方が出て
いろんなところに何でも書けると
その両方初心者が見たときに
どっちがいいんだみたいなそんな感じ
になってしまうので
できるだけその
フレームワークが開発者に
尋ねるところができるだけピュアな
ビジネスロジックを尋ねる
ものにしたいなっていうのが
特にその辺まで最初は考えていなかったんですけれども
作れば作るほど
ピュアなビジネスロジックだけで
いいんじゃないかみたいに
でいけるんじゃないかみたいになってきて
今だと結構
ビジネスロジックを書けば
いいぐらいの感じに
近づいてきてるなっていう
なるほど
Kazunari Okuda
それこそさっきおっしゃった迷いの部分ってすごい
Takashi Kawae
本当にそうだなと思って
言いました
私たちも石板を考えていく中での
その迷いを本当に潰していくっていうところでしょうかね
これはどこに置いたらいいのっていうのを
迷いなく書ける
しかもどう書くかも迷いなく書けるっていう
かなりそれは本当に追求
後になってどんどん追求されていった部分で
現状自分で石板を使ってアプリケーションを書くときに
そういう迷いがほとんど今無くなったなっていう
すごくすっきり
石板フレームワークの開発
Takashi Kawae
書き始めのときにどこに何を書くかを
いちいち考えなくてもよくなった
もうどこから何をどう書いていくか
全部それが一つのストーリーみたいになっていくっていう
それを本当にフレームワーク使う一つのメリット
素晴らしさだなと思います
Kazunari Okuda
確かにそうですよね
ちなみにこのCシャープで書かれてますけど
Cシャープはメインの言語で使われてる感じなんですか
Takashi Kawae
そうですね
私たちの会社ではCシャープバックエンド
ほとんどCシャープで書くことが多いですし
私個人で言うと.NETが最初マイクロソフトでリリースされて
Cシャープバージョン1ですけど
そのときからずっとCシャープを使っているという感じで
個人的には一番好きですし
得意な言語の一つでもあります
会社でもよく使われる言語ということで
Cシャープで始まったというところですね
Cシャープは結構
Kazunari Okuda
あまり書いたことはないのでわからないんですけど
マイクロソフトが開発してる言語でしたっけ
Tomohisa Takaoka
そうなんですね
Cシャープで
追い立ちから考えていくと
わかりやすいというか
ところなんですけれども
もともとWindowsで動くプログラミング言語として
開発されたんですね
それが2000年代前半で
それが一気にハックされて
ユニティとかに使える
ゲーム開発に使われるようになったんですね
それが2010年代ぐらいの
初めぐらいなんですけれども
マイクロソフトがちょうど
GitHubを買ったりして
オープン化を意識し始めたのが
2010年代の最初の方だと思うんですけど
それぐらいからWindowsだけで書けるプログラミング言語
じゃダメだということになって
今はMacでもLinuxでも
動くようになる形で
リリース
アップデートされていったんですけれども
そのアップデートが出たのが
7,8年前ぐらいなんですね
7,8年ぐらいLinuxでもMacでも動くんですけれども
何せ元がWindows専用プログラム
言語だったもので
今でもやっぱりプログラマーの人でも
Windowsでしか動かないんじゃない
みたいに思ったりとか
オープンソースじゃないから
マイクロソフトだけしか決定権ないんじゃない
って思ってる人が多いんですけど
結構普通にオープンソース活動していて
日本人のマイクロソフトにいない開発者の方でも
Cシャープになっている方が結構おられたりしますね
Kazunari Okuda
そうなんですね
そういえば私も新卒で入った会社は
デルファイがCシャープ
元になったというか
デルファイはWindowsのアプリを書く専用
そこからいろいろ派生していって
今のCシャープができたような話を
聞いた気がしますね
Takashi Kawae
そうですね影響を受けている
Kazunari Okuda
懐かしいしデルファイは
Tomohisa Takaoka
懐かしいですね久しぶりに聞いた
学校でデルファイ書きました
学校で書いたんですか
学校で書いてましたね
授業で出てたっていうよりも
卒業研究とかをする
研究室みたいなところで
先生がデルファイ使っていて
書いた気がしましたね
C++にするかデルファイにするかで
どっちでもよかったんですけど
デルファイの方が好きだったので
Kazunari Okuda
デルファイで書きました
確かに珍しいですね
大学とかそういう学校だと結構
私の時はJavaかCやC++とか
結構多かったですね
デルファイっていうの聞かなかった
私が新卒で入った時の会社で
デルファイ開発してた時も
デルファイってちょっともう
かなりあるような言語でした
Takashi Kawae
正直
Kazunari Okuda
元々はねとてもいい言語
Takashi Kawae
開発ツールも優れてたんですけどね
Kazunari Okuda
そうですね
いろんな言語が出てきてて
今残っていることをちょっと
どうなのかな
Tomohisa Takaoka
Cシャープは一応
先天的に言うと
プログラミング
Language of the Year 2023に
選ばれたりして
一番使われているわけではないですけど
上昇気流みたいな感じで
2023年一番上がっている言語と
言われていて
毎年大きな機能開発がされていて
個人的には
80、90点くらいには
なってきてもうちょっと頑張ってほしいな
っていう感じですけど
よくなってきてはいますね
Kazunari Okuda
そうなんですね
いいですねCシャープ
ウェブアプリにも書けるんですよね
ちなみにその場合ってフロントエンドはどうなんですか
Takashi Kawae
Cシャープをバックエンドで
Kazunari Okuda
Cシャープを使う場合ってことですよね
そうですね
Takashi Kawae
UIもCシャープができたりするんですか
データベースの採用
Takashi Kawae
そうですねCシャープでフロントエンド
ブレイザーという技術が
結局全部マイクロソフトではあるんですけど
ブレイザーというマイクロソフトのフレームワークを使って
フロントエンドもCシャープで書くことはできます
ただ
私たちの会社ではフロントエンドの方は
Cシャープ書けなくはないんですが
やっぱりタイプスクリプトとか
いわゆるリビューとかリアクトとか
一般的なフロントエンドのフレームワークを使って開発する方が
楽という部分もどうしてもあるので
そっちを使うことが多いですね
Kazunari Okuda
なるほどですね
マイクロソフトはタイプスクリプトとかも開発してるし
フロントエンドを別にCシャープを使わなくても
全然JSとの親和性とかありそうですよね
じゃあ石板の話に戻って
この石板自体は
データベースも結構採用してるというか
Amazonのデータベースとか
マイクロソフトのデータベースも採用してて
イベントソーシングの結果自体も
そちらに保存できるようなアダプターみたいなのも
対応してるっていうことですか
はい
アダプターは
Tomohisa Takaoka
そうですね
AmazonのAWSのDynamoDBと
マイクロソフトAzureのCosmosDB
そして一般的に使える
PostgreSQLにも対応している
今その3つに対応しているという感じですね
Kazunari Okuda
なんかそのDynamoとか
PostgreSQLは
みんなが使ってるというか
データベースとして
わかりやすいんですけど
マイクロソフトとかAmazonのDynamoDBとかを
対応したきっかけというか
石板の中で
そこに保存した方がいいみたいな
モチベーションみたいなのがあったら
Tomohisa Takaoka
お聞きしたいんですけど
そうですね 最初に対応したのがCosmosDBだったんですけれども
最初なぜ対応したかというと
私たちがAzureを使っていることが多くて
Azureでドキュメントデータベースですね
JSONで保存するタイプのデータベースで
探したところ
Cosmosだったので
Cosmosあんまり使ったことなかったんですけれども
色々調べてみると
大規模システムの対応が強い
結構たくさんのデータが入ってきても
ハンドルできる 私たちはそういうシステムを
作りたかったので
これまではRDBばっかりだったんですけれども
CosmosDBでスタートして
それを
AWSでも使えたらいいなということで
似たようなコンセプトのDynamoに対応したと
ポスグレは逆に最後で
ポスグレはパーティション対応
というんでしょうかね
たくさんのパーティションに分ける対応が
ドキュメントデータベース並みに強いということだったので
結構イベントソーシングでも採用されている
実例が多くて
だったら採用したらいいんじゃないかと思って
ポスグレも最終的に採用した
という感じになります
Kazunari Okuda
そうですよね
イベントソーシングは私も
実際に使われていることは
ある現場があったんですけど
結局
今の状態を保存しないということなんで
今の状態を計算するために
イベントを保存しているんですよね
イベントの数がすごく多くなってくるということが
アプリケーションにどういう風に使うかによるんですけど
イベントを全部それに対して保存して
実際に今の結果とか
ある時点での
どういう状態だったのとかを見る場合は
そのイベントをどんどんアプライしていく
そのイベントの計算
高速に
イベントがたくさんある場合というのは
結構あって
だからこういうDynamoとか
Cosmos DBに対応していらっしゃるのかなと
ちょっと思ったんですけど
Tomohisa Takaoka
どうですか
ちょっと僕も
これを始めてからドキュメントデータベースを
使い始めたので
どっちが先かというのは分からないんですけれども
イベントソーシングと
ドキュメントデータベースに共通する要求として
パーティションが
たくさん分かれていないといけない
っていうのがあるんですね
Cosmos DBとかも
基本的に一つの
例えばアイテムというテーブルを作って
そこにすごいたくさんのデータを入れても
基本的にはパーティションがちゃんと分かれていれば
それが別データとして
ちゃんと扱えるようになっているんですね
それが結構
イベントソーシング的には重要で
全体の量がたくさんあるということは
一つ大切なポイントですけれども
かついろんなパーティションに分けて
このパーティションのデータだけが
欲しいってリクエストしたときに
それに対応できる設計のデータベースっていう
パーティション対応っていうのが
決め手になったかなと思っています
Kazunari Okuda
なるほどですね
イベントソーシングの適用範囲
Kazunari Okuda
イベントソーシングを使って
実際に
よかったというか
これにマッチしてたよな
こういうアプリケーションには
すごいマッチしてたよなみたいな例ってありますか
もし話せる範囲でいいんですけど
例えば何か
Takashi Kawae
そうですね
例えば社内で使われているケースということであれば
先ほど友人さんがおっしゃった出待機のアプリケーション
これはまさにぴったりなのかなっていうところで
結局
出勤退勤のタイムカードを記録していく
その事実をずっと時系列で記録して
それを蓄積していく
という点でまさにそれは
そのデータそのもののイベントですから
それをそのままの形でデータに保存してしまう
一つ一つをステートと捉えるのではなくて
誰かが出社した
退社したというイベントですね
あとになって最終的に
例えば週単位であったり月単位であったりで
それを集計するなりあるいは
例えば残業の時間を計算するとか
そういうところも後になってそのイベントを全て再生して
そして統計を取ってまた別のデータの処理に使っていく
という点ではイベントソーシング
Kazunari Okuda
ぴったりなんじゃないかなという気がしていますね
確かにそうですね
確かに例として思い浮かばなかったんですけど
例えば出勤と退勤だけじゃなくて
例えば途中で抜けましたみたいな
例えば
廃社とか医者に行くのに一旦仕事を抜けました
というイベントとかもここからここまで抜けました
というのは
別に欠けない今の状態を保存することで
表せないことはないんですけど
イベントソーシングがここからここ
働き始めました
ここで抜けましたそこは戻ってきました
退勤しましたみたいなのは
Tomohisa Takaoka
イベントソーシングは確かに
あとは一つの
一つのものに対して
いろんなものが影響を与えるもの
っていうんですけれども
例えば分かりやすいのは
ウーバーとかウーバーイーツみたいな
今回のオーダーに対して
レストランにこの情報を送って
レストランの人がOKボタンを押しました
そして配達の人が行って
そして配達の人が
その荷物を取ってきて
それを移動しているときに
その情報をアップデートして
そしてその情報を逐次アップデートしつつ
イベントソーシングの利点
Tomohisa Takaoka
最初にオーダーした人が受け取って
受け取ったときにレビュー書きました
いろんな人が関わっている
一つの情報というのがあって
それに対していろんな人がアクセスしていく
みたいな
最後にレビューを書いて
この情報に関してはデータをクローズする
みたいな
そういうものに関しては非常に強くて
結局ステートの考え方がもう
不要になるというか
今どうなのかというのはもちろん知らなければいけないんですけれども
それよりもどんなことが起きているのか
ということのほうが大事な
ビジネス的にはこういう話で結構多いと思うんですけれども
サービスをビジネスで
解決するみたいな
いろんな人が一つのものに
レビューしたり検索したりするみたいな
そういうときのものが結構向いているなと思っている感じがします
はい
Kazunari Okuda
それは本当に思いますね
あと特に始まりと終わりが明確なものとか
イベントソーシングとか
結構適してるな
Tomohisa Takaoka
確かに
オークション的なものとかですね
例えばそうですね
結構得りやすいかなと思いますね
Kazunari Okuda
そうですね
Tomohisa Takaoka
でも私たちはもう頭が
イベントソーシング脳になってしまって
今聞かれた
こういうビジネスのアイディアがあって
イベントソーシング使えると思いますか
使えないと思いますかって聞かれたら
大体オークのケースで
いやもうこれイベントソーシングでいいんじゃないって思っちゃう
なんていう考え方になってしまっているところは
ただそれを
いろんなものを作って
証明していきたいなという
そういう風に今考えているところです
Kazunari Okuda
なるほどですね
逆にそれを証明していくっていうのは面白いですね
既存のシステムが
ステートを保存しているようなものではなくて
これがイベントソーシングでも
の方がいいですよっていうのは
多分なかなかそれ
結構今までアプリケーション開発してきたんですけど
やっぱりドコモンは結構
今のステートを保存している状態っていうのが
当たり前のような気がしているんですよね
そうなんです
Tomohisa Takaoka
そんな中で
Kazunari Okuda
イベントソーシングの方がいいですよっていうには
なかなか証明していかないと
この当たり前の状況からバイノリティが
広めていくには
それが一番の方法かなとは思います
そうなんですよね
Tomohisa Takaoka
結構最初に作り始めて
最初の時に
このイベントソーシングだと
こういう問題が解決するかもしれないと思った時に
僕もかわいさんも
20年間
データベースを使って
システムを開発してきて
20年くらいそのステートを保存して
何かあったらそのステートを変更して
それを保存するっていうのをやってきたんですけれども
これはもうついに
今までの20年やってきたことと
全く違うコンセプトに
たどり着いたみたいな
もちろんイベントソーシング自体は
10何年前からあって結構使われてるんですけれども
私たちが知らなかったので
こんな
全く今までと違うことが
コンセプトで書けるものなんだっていうので
びっくりして
それを作り始めたっていう感じがありますね
なるほどですね
Kazunari Okuda
別に
一つのアプリケーション内で
必ずしも全てがイベントソーシングである必要は
結構なくて
イベントソーシングを使うことの利点っていうのは
ある特定のパターン
イベントソーシングを使って
データ解析とか
そういう部分の
例えば集単位で
数の集計とかは
永続化したいよねっていう場合は
別にそれで
イベントソーシングを使う必要がないというので
普通のパターンというか
Tomohisa Takaoka
それを
そうなんですよね
イベントソーシングもやっぱり
グレッグ・ヤングっていう人で
彼のYouTubeを見ると結構色々わかりやすく
説明してるんですけれども
イベントソーシングはマイクロサービスと非常に
親和性が高くて
何でかっていうと
過去のリストが
例えば1テラ2テラあったとして
そのデータをコピーして
別の場所に持っていって
もうローカル解析してしまえばいいんですね
ローカル解析して
マテリアライズドビューというか
普通のRDBに集計データみたいなのを
作るというのを別でやってしまえば良くて
1テラ2テラが終わった後に
また次の日10ギガのデータが
できましたという時に
1テラプラス10ギガのデータを送る必要はなくて
新しいデータの
10ギガだけを
マイクロサービスに送ってあげればいいんですね
つまり
その前は変わらないっていうことが
基本的に保証されているので
新しいデータだけを各地に
分散して送ってあげて
処理すれば良い
そうすることによって
過去のデータも変わっているかもしれないという
ステートの状態だと
全部調べて新しいレコードだけ
に関しては全部送るみたいな
それをすると結構大変なんですけれども
本当に差分だけでやればいいというので
マイクロサービスとの親和性がすごい良いという
のも利点としてはありますね
関数型プログラミングによる書き方の変化
Kazunari Okuda
なるほどですね
確かに
イベントソーシングというのは過去のデータは書き換え
イベントが起きたことは
基本的にそれを変えられない状態で
保存していますよね
それが前提としてそういう風にあるので
あればそういう方法も
確かに可能というか
Tomohisa Takaoka
簡単ではなく
実際には簡単ではなくて
本当に間違えて保存してしまったイベントを
キャンセルするイベントを
作らなきゃいけなかったりとか
単純に本当にあったものを削除する
イベントを定義しなきゃいけなかったり
本当にビジネスロジックごとに
細かなイベントを作る必要が
出てくるというのはあるんですけれども
実際その新しいイベントを定義するというのが
テーブルを定義するよりは
コードでできるので
簡単にできるというのがあって
変化に強いシステムを作りやすいというのは
ありますね
Kazunari Okuda
なるほどですね
このプロジェクトなんですけど
石板なんですけど
関数型も取り入れていらっしゃると
そこら辺の動機
関数型をなぜ導入したのか
そうですね
Tomohisa Takaoka
お話できますか
関数型に関しては
半分趣味なところがあって
いろいろ書き方とか
スマートに書けるとかを
すごい気にするようになって
こう書いたらいいんじゃないかとか
こういう書き方だったらここにフォーカスできて
バグが減るんじゃないかとか
いろいろ考えた中で
最近結構関数化ドメインモデリングっていう
有名な本が日本語に訳されたりもしたんです
ちょうど先月末ぐらいに
発売開始になっているんですけれども
そういう関数型で
ドメインモデリングを書いたら
綺麗ですよみたいなのを
いろいろ読んでいたらやっぱり
石板にも取り入れたくなってしまって
関数型ファーストの
フレームワークに
最近なりつつあるんですけど
会社の社内の人にも説明して
いろいろ説明してみて思ったのは
関数型は慣れればすごい良いんですけれども
慣れるのに
時間もしくは
スキルみたいなのが
いるところがあって
みんなが関数型だけを書くようにするには
教育が大変だなと思うので
手続き方っていうんでしょうかね
普通に処理を上から書いていく
みたいな形の
対応はある程度はちゃんと残していこうかなとは
思っています
Kazunari Okuda
川合さんは
関数型と宣言型に対して
何か思うことはありますか
Takashi Kawae
ともひささんおっしゃった通りの部分で
趣味的なというところもあるんですけど
もう一つは
さっきのきれいにとか
効率的なというところとも
重なってくる部分があるかなと思っていて
どう書くかではなくて
何をやりたいかに注目したかった
そこにフォーカスを合わせて
そこに集中させたいっていうところが
やっぱり大きかったと思うんです
結局手続き型に書くか
それとも宣言的にという言い方もできると思うんですけど
宣言的か手続き型かっていう
そういう議論の中でいくと
どういう風にロジックを組み立てるか
それに時間を使いたくない
自分たちの場合
住宅開発というところがありますので
お客さんの要件を聞いて
実際にそれをソースコードに落とし込んでいく中で
お客さんの方は
私たちがどういうソースを書いたかには興味がない
信頼性が高い
そして満足のいく自分たちが欲しいと思っていたものを
作ってほしいと思っている
いろんなリソースを持っていかれたくない
そういう考えた中でプログラミングがより宣言的に
これはどういう役割を果たすのか
これはどういうものだということを書いていくと
必然的にオブジェクト思考でいう
オブジェクトの役割
その重要性が下がってきている
という風に石板の開発の中で感じた部分はあります
実際にデータを持つもの
そして実際に処理を司るもの
ファンクションですよね
そのものとことがだんだん分離していくというんでしょうか
その過程で必然的に宣言的なプログラミングの
方向性にどんどんシフトしていった
というところはかなりあるかなと思います
新しいチャレンジとモチベーション
Kazunari Okuda
なるほど
この石板内部はそうで
実際に石板を使うコード
多分呼び出したりするじゃないですか
その部分も関数型のように書かれている
のように呼び出すということですか
そうですね
Tomohisa Takaoka
どっちかというと
使う人が関数型で書くように
内部のコードは全部書き換えていたら
とてつもなく時間かかってしまうので
インターフェースを関数型ぽくしていっている
内部のコードは全部書き換えていなくて
必要な分だけ書き換えているんですけれども
使う側が関数型で書けるように
意識しているという感じですね
さっきカズさんが言ったように
いろんな人が
いろんなところにコードを書きたいみたいな
のがあって
その書き方によっていろいろ
好みが変わるみたいなのがあるんですけれども
千言型で書いてしまうと
例えばコマンドであれば
バリデーションのコードを
1から書いていくというよりも
この値は1から100までしか
入りませんみたいな
アトリビュートというか属性的なものを
付けることによって
プログラミングコードというよりも
普通にタグ付けしているだけみたいな感じで
千言的に
条件を書けるようにすることによって
例えばif文とかはもう
書かなくてよかったりとか
そういうふうにして
短いコードでたくさんの意味を
生産性を出せるみたいなことを考えて
いろいろ書いてきた結果
そのうちの1つが関数型っていう
Kazunari Okuda
いいですね
やっぱり
オピニオネイティブな機能ということで
作っている中で
自分たちの欲しいものとか
やりたいことっていうものが
元々はそこから生まれて
石板が生まれて
そこから改良していくのにも
自分たちがこうしたいという思い
いろいろなモチベーションがあったりする
と思いますけど
その中で新しいものとか
こういうチャレンジをしてみたいっていう
なかなかこういうのって
イベントソーシングの利点と開発安心感
Kazunari Okuda
アプリケーション開発していると
新しいのを取り入れるのって
ちょっと躊躇する部分はありますし
なぜなら受託とかそうかもしれないですけど
早く早く
結構期限とかあるじゃないですか
そこのプレッシャーがある中で
Tomohisa Takaoka
新しいものをトライしていくっていうのは
Kazunari Okuda
あんまり必要性が出てこないですよね
でもこうやって
自分たちがやっていきたいことっていうのが
入っててそれを
かつOSSで
出してはいるんですけど
そのこだわりが入っているっていうのは
いいですね
Tomohisa Takaoka
ありがとうございます
よく川谷さんと話すのが
これ自分の一つのプロジェクトの中の
共通コードだったら
これ絶対変更しないよねっていうような変更を
結構していて
これまでのコードを効率的にするだけじゃなくて
次に書き始めるときに
一番効率的なコードになったらいいなと思って
書き換えているので
若干の前のコードの修正とかは
やっぱり発生するんですけれども
これも将来もっと効率的な
コードを書きたいなという気持ちでやってます
Kazunari Okuda
なるほど
いい
すごいいいプロジェクトですね
しかもこれをオープンソースにすることによって
私たちはこういう
ことをやってますよっていうか
こだわりっていうものも同時に見せられるような
そうですね
Tomohisa Takaoka
名刺代わり的なところももちろんありますし
本当はいろんな会社さんに
使っていただいて
効率化になったのを
見ていただきたいっていうのは
あるんですけれども
一番のモチベーションはやっぱり自分たちが
一番効率的に開発したいということなので
逆にオープンソースのプレッシャーみたいなのも
それが良い方向に働いていて
社内向けだけだったらここまでしないよなっていうような
ドキュメント書いたりとか
インターフェースをきれいにしたりとか
そういうのまで手をつけているのはやっぱり
みんなに見られているプレッシャーみたいな
実際見てる人はほとんどいないんですけれども
そういうような
オープンソースにして良かったなと思っていますね
Takashi Kawae
確かにそうですね
オープンソース見られているっていうところで
例えば内部の一つ一つのインターフェースだったり
クラスだったり
名前を付けるところ
結構初期
名前付けだけでもかなり時間を使いましたよね
でもそれも実際
社内だけだったら動けばいいわけで
そんなにこだわらなくてもいいところですけど
でも実際名前付けって重要じゃないですか
名前を見てその一つ一つの振る舞いが分かるかどうか
っていうのも多分質の高いソフトウェアの
一つの条件になってくる
その辺りもやっぱり公開しなければいけないっていうところが
一つモチベーションを高めるのに繋がっているというのはあると思うんですね
Kazunari Okuda
確かに確かに
そうですね
社内だけであれば妥協しちゃうような名前付けも
確かに公開することで
分かりやすい名前にするっていうのが
モチベーションになります
あとこのプロジェクトの名前の石板ってすごいいいですね
まさに石板だなと思って
Tomohisa Takaoka
そうですね
いろいろ考えたんですけど
いろんな言語でも響きの良い名前みたいなので
出してくださった中から
選んだんですけど結構気に入ってます
Takashi Kawae
そうですね
最初いくつか案があって
アイデア自体は友人さんが出されて
やっぱり書いて消せないっていうんでしょうかね
永続的な記録を残すっていう
その発想の中でいくつか単語が出てきたところで
石板はどうかなっていうところがありましたね
発音的なものも
日本語なんだけれども
例えば他の言語の人たちが発音したときでも
そんなに言いづらくないんじゃないかなとか
結構そういう単語ってあるじゃないですか
やっぱり他の外国の人がちょっと発音しづらいみたいな
そういうのもあえて日本語で出すんであれば
音としてで
せめて発音しやすいような
そんなところもちょっと考えてありました
Kazunari Okuda
ありますよね
盆栽とか
そのまま書いて読むとバンザイみたいに呼ばれて
英語圏ではバンザイみたいな
Tomohisa Takaoka
なるほど
Takashi Kawae
確かに
Kazunari Okuda
名前付け大事ですよね
石板いいですね
他にどういう候補があったか覚えていらっしゃいますか
カラス見とかありましたよね
Takashi Kawae
ありましたね
Tomohisa Takaoka
あと何だっけ
Takashi Kawae
いくつかあって何でも覚えてない
僕もなんか
Tomohisa Takaoka
記憶が上書きされてしまいました
Takashi Kawae
この石板で
出したら割とすんなりこれで落ち着いて
すごい馴染んじゃったっていうところが
方法自体忘れてしまったっていう
Kazunari Okuda
すごいいいと思います
まさにおっしゃった通り
書き換えられないというか
しかも石板の方が
紙よりも全然残りやすいというか
確かに
Takashi Kawae
旧石時代のものでも紙に書いてたら今も残ってないですけど
Kazunari Okuda
石板として石に刻んでる方が
全然残るとは思ってて
まさにそんな感じで
イベントがちゃんと残ってる感はありますよね
結構やっぱりステートだったら
ステートでプログラミングしてると
ステートでプログラミングしてると
Tomohisa Takaoka
ステートでプログラミングしてると
やっぱり
SQLのサーバーの設定にもよるんですけど
SQLのサーバーの設定にもよるんですけど
このデータがあるはずなのに
どこ探してもないとか
これ誰が書き換えたのみたいなのが
本当にちゃんとヒストリーを取る
プログラムを書いていないと
わけのわからないデータが残るみたいなのが
あるんですけれども
デバッグして感じるのは量が多くなって
たくさん見なきゃいけないっていうのはあるんですけれども
このイベント来てこのイベント来て
デバッグはしやすくなったなという風に感じます
Takashi Kawae
うん
Kazunari Okuda
それは本当にありますよね
あとなんか
プログラミングの制限とサブタイピング
Kazunari Okuda
例えばコードにバグがあって
結果的にそれが保存されている場合とか
間違ってですねあった場合でも
やっぱり上書きなんで
全然わからないその状態になった結果
結構それはもうデバッグ大変ですよね
大変なんですよね
Tomohisa Takaoka
脳内メモリでマルチスレッドで
このスレッドではこれがこうで
あのスレッドではあれがだったから
もしかしてこういう状況でこういうデータが出たかもしれない
結構そういう脳内デバッグで
やらないといけないこと実際多いですね
そういうのがやっぱり
気になって作り始めたっていうところ
Takashi Kawae
安心感
赤板もそうですけどイベントソーシングで
データを書いていくとすごいこう
開発者として安心感が全然違うんですよね
なんかステートソーシングの時だと
さっきおっしゃられたような
間違って書き換えられるかもしれないとか
前の状態欲しくなった時じゃあどうするとか
そういうこといつも考えてなきゃいけないし
場合によってはそれを考えたスキーマンにしていかないといけない
ところがあって
実際それも本来のアプリケーションのビジネスのロジックに
集中しづらくなる一つの要因だと思うんですよね
失われたらどうしよう
でもイベントソーシングであればとりあえず全部
記録が残っているので
バグも含めて間違ったものも起きたのは
事実であることには変わりはないので
そうしたものも含めて全部の事実が残っている
それは本当に開発していて安心感
Kazunari Okuda
全然違うなっていう風に思います
あとパッと思いついたのが結構
結局
イベントログを保存しているんですよ
何が起きたかっていうのを
今考えていると
例えば物を買いませんで
eコマスのサイトだったりして
結局この購入者が何をしたか
最終的には
欲しいんですよ
Tomohisa Takaoka
結局同じものを保存しているっていう
ステートで作っています
Kazunari Okuda
そうなんですよね
eコマスのサイトで私は働いているんですけど
よく考えるのは
eコマスの場合でも今というか
結構従来のやり方でイベントソーシングを
使わずにやっているんですけど
イベントソーシングを使えないかどうか
結構考えたりするんですよね
何かの注文があって
注文がどう変化していくのか
っていうのを考えた時に
イベントが増えることに
例えば注文のテーブルが
オーダーだったとするじゃないですか
そこにどんどんカラムが追加されていくんですよね
いつキャンセルされたとか
でもいつリファウンドされたのか
それを別のテーブルに持つことができるんですけど
最終的に
イベントが起きて
オーダーというモデルに対して
リファウンドのイベントが起きてとか
そっちの方が
最終的に
オーダーのモデルっていうのはすっきりする?
イベントソーシングを使った方が?
そんな気はしてるんですよね
Tomohisa Takaoka
データにポリモフィズムを
導入できるっていうのが
イベントソーシングの利点の一つでして
つまり
キャンセルイベントを受け取ったら
内部的な型っていうのを
キャンセルドオーダーみたいなものに
メモリの中の型は
コードの型を変えることができるんですね
そうすると何が起きるかというと
キャンセルされたという型になっているものに対して
データを追加したりとか
そういうアクションが
オブジェクトに対して行うことができないように
制限かけることができるんですね
キャンセルオーダーを元に戻すためには
キャンセルのキャンセルみたいな
普通のオーダーのアクティブオーダーに戻す処理みたいな
イベントを送ってあげないと
その型が変わらないので
また何かしたいときは追加のイベントをしないと
型が変わらないという
そういう風にすることによって
今何ができるのかという
選択肢をプログラミング上で
最小限にすることができる
これは結構実際に実装するのには
技術がいるんですけれども
そういう風にすることによって
型によって制限されるプログラミングみたいな
プログラミングできるというのは利点の一つですね
イベントソーシングの広まりについて
Kazunari Okuda
なるほどですね
そうですね その型があることによって
より安全に処理ができるというか
安心してコードが書けるというのはありますよね
Tomohisa Takaoka
サブタイピングみたいなね
そういう表現で結構最近注目されているところがありますね
Kazunari Okuda
なんかあれですね
もちろん石板を多くの人に使っていただきたいというのはあるかもしれないですけど
イベントソーシング自体を広めていくようなことができれば
より石板にとってもいいかもしれないですし
イベントソーシング自体の実証実験じゃないですけど
こういうビジネスモデルに適応してみた結果
イベントソーシングの方が良かったとか言えたりとか
ブログとかいろんなところで
受託なんでそれを全部公開できるわけではないと思うんですけど
それによってよりイベントソーシングを広める方にいけると
いいかもしれないなと思いました
Tomohisa Takaoka
本当にそういうふうに今考えていて
イベントソーシング好きの方が
ツイッターにも日本人でも何人かおられて
そういうイベントソーシングカンファレンスみたいなのを
もしかしてやるかもしれないとか
そういう話も少し出始めたりしていて
少しずつ機運が高まっていて
普通にイベントソーシングを採用したいと
イベントソーシングの開発秘話
Tomohisa Takaoka
みんなが思うようになれば
逆にCシャープで書けるのは何だろう
石板っていうのがあるねっていう
Kazunari Okuda
そういうパスもあるかなと思って考えていますね
そうですね
あとはイベントソーシングで思うのは
管理者画面とかも結構統一化できそうかなと
個人的には思っていて
結局アドミンの人
どういうことが起きたのかとか
こういうイベントがあったけど
キャンセルしたいですとかっていうのも
結構起きてくると思うんですよね
そういう中でUI
イベントソーシング用のアドミンじゃないけど
Takashi Kawae
そういうのもあるかな
Kazunari Okuda
アプリケーションによると思うんですけど
Takashi Kawae
アプリケーションの必要性
Kazunari Okuda
需要というのもあるかもなとかって思いましたね
Takashi Kawae
確かに
Tomohisa Takaoka
SREの人がデータ見ずに
まずそういうなんていうか
ウェブシステムでパパパッと
イベントだけ見て対応できるとかは
Kazunari Okuda
自動的に作りやすいかもしれないですね
そうですね
という感じで結構ざらっと喋ったんですけど
他に話し忘れてることとかありますか
石板について
ここが喋りたいんだよなみたいなところってあります
Tomohisa Takaoka
一応言おうと思って撮ってたんですけれども
最初にバッティング
ピッチャーとキャッチャーみたいな感じだったって
河合さん言ってくださってますけれども
どっちかというと私の方から見ると
プレイヤーとコーチみたいな感じ
僕はコード書くのが好きなので
ガンガンコード書いていくんですけど
やっぱり最初はすごい汚い感じだったんですけれども
河合さんは結構言語の知識が豊富で
この機能使ったらこういうのできるんじゃないとか
効率化できるんじゃないっていうのを
いろいろ治してもらって
それでどんどん良くなっていったっていうところがあるので
キャッチボールはキャッチボールでも
コーチとキャッチボールしてるような気分で
僕は開発してました
Takashi Kawae
謙遜なコメントで
ありがとうございます
でも本当その点で言うと
ともひささんのですね
コードを書かれるスピードと
そこにコミットした時ですよね
その出来上がるスピードとそのクオリティが本当にすごくて
エンジニアにもいろんなタイプがいると思うんですけど
ともひささんも本当に
手が先に動けるタイプっていうんですか
何か発想があったら
考える前にまずどんどん書きながら修正していけるっていう
そこは私本当にリスペクトしていて
逆に私は特性としてはあんまりプログラマー向きじゃないというか
書く前にものすごく考えちゃうタイプなので
だからそういう意味で言うと
私が考えたことをともひささんがどんどん具現化してくれるっていうんでしょうかね
私が自分で考えて自分で書くよりも
その考えがともひささんによって何倍ものスピードで具現化される
この循環っていうのはすごく
特に初期の段階ですか
あったんじゃないかなと思っていて
そういう意味でのボールのやり取りみたいなところ
それは感じました
だからすごくそういう意味で私は自分が
自分一人ではとても書いてたら
チームワークと石板の開発
Takashi Kawae
それこそ時間がかかりすぎて
とてもじゃないけど業務の合間にできるようなものじゃないなっていうことを
それをともひささんがどんどん実現していってくださった
その一つの形が今の石板っていう
とても良いフレームワークになったなというふうに思いますね
Kazunari Okuda
なるほど
お互いがないところというか
お互いの良いところが組み合わさって
チームワークですよね本当に
河合さんのおっしゃることわかります
僕はどちらかというと手を動かすタイプより
結構考えちゃうタイプで
でも結構考えるだけだと
やっぱり前に進みづらいところがある
しかも書いて形にした方が
より整理というか
考えたことが整理されて
より道筋が立ちやすくなるっていうことがあると思うんですよね
形にしてそこから良いところ悪いところ
またより考えやすくなるっていうことがあるんで
その2つの組み合わせの結果で
素晴らしいプロジェクトができたということで
良いですね最高のチームワークだと思いますね
Takashi Kawae
ありがとうございます
Kazunari Okuda
楽しみですねこのプロジェクトがどんどん進んでいって
ブラッシュアップされていくのが本当に楽しみです
他に何かございますか
Tomohisa Takaoka
そうですね最後に宣伝的に言いますと
JTECの石板というGitHubにありますので
使う予定のない方もぜひスターだけしていただけると
嬉しいなと思っておりますので
聞いている方で何か今日の話面白かったなと思ったら
ぜひスターしていただけると嬉しいです
Kazunari Okuda
はい私やりますね
あとそうですね
こういう新しいチャレンジをされている会社の方も
興味あればぜひコンタクトして
私の自宅ということでお仕事とかにつながると最高ですね
Tomohisa Takaoka
ぜひぜひツイッターとかホームページもありますので
JTEC Japanぜひ見てみてください
Kazunari Okuda
ショーノートの方に記載していきますね
ということでいい話が本当に聞けました
開発の背景からどういうところまでが
モチベーションとして
こういうものが作りたいというところから始まって
このプロジェクトができて
2人でブラッシュアップしていって
OSSにつながったということで
とてもいい話が聞けましたね
本日はありがとうございます
ともひささんかわいさん
Tomohisa Takaoka
ありがとうございました
Takashi Kawae
ありがとうございました
01:26:14

コメント

スクロール