#442 イベント履歴式ドメインモデルってなんぞ？？

この番組は、エンジニアの成長は楽しい学びからをモットーに、昨日より少し成長できる学びを届けるエンタメ系テックラジオです、ということで。

よろしくお願い申し上げます。

はい。

じゃあ、昨日よりちょっと成長していきますか、というところで。

おわ、出た。肩に力が。

本日はですね。

入っていない。

肩に力は入ってないですよ。

リラックスしている。

もう、本当に豊かな気持ちです、今日は。

豊かな肩。

はい。それはなんか、新しい、そのボディビルの大会の掛け声みたいな。

豊かな肩。

1周回って超シンプルになるみたいなね。肩に。

ああ、マッチョの気乗せてんのかいとかっていろいろ、いろいろあった末の豊かな肩。

いいね。マッチョを豊かって表現するのいいね。

はい。マッチョは豊かだね。

筋肉豊かだねって。

確かに。

いいね。まあそんなこと置いといてですよ。

はい。

えっとー、まあ去年からちょっと継続して読んでて、お仕事が少し落ち着いたんで読書を再開してですね。

おお。

えーと、ドメイン駆動設計を始めようという本があるんですけど。

お、ブラド、この、こののぶさんのやつ。

あ、うん、そう。ちょっとなんて読むか分かんないですけど。

うん。

えっとー、なんかエリック・エバンスのドメイン駆動設計、むずすぎて、こっちは分かりやすいぞみたいな噂をかねがね聞く、この本なんですけど。

はい。

まあ私も同じ印象でですね。

うん。

まあ楽しく本を読んでおるんですけど。まあ今日はその中のですね、えー、イベント履歴式ドメインモデルっていうものがありまして。

うん。

はい。まあちょっとこちらを軽、軽くって言ったらあれですけど、まあわいわいちょっとお話しできればなあというのが今回になります。

なるほどね。

うん。

随分難しそうな単語が出てきましたけど。

本当にね、なんか、ちょっと伝わるか分かんないんですけど、なんかメタルグレイモンみたいな名前ですよね、なんかイベント履歴式ドメインモデルって。

でもちょっと分かんなかった、すごく。

そうだね。メタルグレイモンは知ってるんですけど。

なんかその、単なるグレイモンじゃなくてメタルが付いてるみたいな。単なるドメインモデルじゃなくてイベント履歴式が付いてるみたいな。

ああ、なるほどね。そこを変えてね。

単語の単語をガーンってやることによって、まあ少し概念として進化しているっていうタイプの命名です、これは。

なるほど。

なるほどね。

まずね、で何の話するかちょっとよく分かんないと思うんで。

うん。

うんと、まあいろいろちょっとおさらいしてしながら、まあやっていければなと思うんすけど。

うん。

まずそもそもドメイン駆動設計の話から。超軽くおさらいなんすけど。

はい。助かります。

えー、まずドメイン駆動設計っていうのはソフトウェアの、まあ設計手法っていうのかな。で、で、まあ詳しいことは言わないんですけど、ざっくり現実のお仕事、業務を、うーん、なんだ、モデル化してっていうと難しいので、まあ現実のお仕事と同じような動きするソフトウェアを作ろうみたいなのが、まあ根本のやりたいことになってるのかなと思ってます。

うん。

でもう少し踏み込むと、現実のお仕事を、まあモデル化して、なんて言えばいいんだろうね。

いやでもモデル化がなんか1番僕はしっくりくるなと思っていて。

通じるかな。

家建てるときにさ、あ、家建てるときにっていうか、なんかマンションのなんかちっちゃいバージョンみたいなやつあるじゃないですか、その部屋のイメージをつかむための模型みたいな。

模型、ああそう、模型、模型。なんかそういう意味でのモデルって捉えるとなんか1番つかみやすいかなと思っていて。

うん、まあそうっすかね。

実物とは全然違うじゃないですか、素材も何もかもが。

うん。

でも形のイメージはつかめるじゃないですか。

うん。

そういうものをモデルと言ってるような気がする。

うん。

うーん。

まあ立体物だとまんますぎるから、実はじゃあ間取り図みたいなのが近いっすかね、ひょっとしたら。

うーんと、うーん、どうだろうな。いや、なん、なんて言うんだろうな。その、イメージをつかむためのモデルというか。

はい、はい、分かります。イメージをつかむためのモデル、はい。

って思ってて。で、このドメインモデルに関して言うと、ドメインっていう複雑なものがあるけど、まあそれって要は、えー、いろんなものを蒸留して、削ぎ落として、必要な部分だけ残して、分かりやすく表現すると、こうなるよねっていうモデルを作るものみたいなイメージなんすよね。

うん、うん、うん。もうそうとしか言えない。まあでもそうなんだよな。

要は、ドメインっていう現実のものがあって、それを表現するものが、それをなんか分かりやすく小さくしたものがモデルみたいなイメージっすかね、なんか。

うん、まあそうですね。なんか具体的なことを言ってみるとですね、えー、まあじゃあベタにToDoアプリを想像してみましょうと。

うん。

はい。で、まあToDoアプリを想像すると、まあアプリケーションの画面が出てくると思うんですけど。まあきっと多分あなたが今想像したToDoアプリって、ToDoがなんかリストで並んでて。で、そのToDoになんかタイトルとか、あとまあなんかブレイクダウンした説明みたいなのが付けれて。

うん。

で、そのToDoは作成とか削除とか更新もできるし、あとはなんかステータス的なものを持ってると。えー、ステータスはだからToDoなのか。

うん。

ダーンなのかぐらいかな、一旦。

そういうことね、はい。

うん。まあみたいな、まあToDoアプリを想像しましたと。

はい。

思ったときに、まあちょっとこっからアーキテクチャーの話になってくんですけど。えーっと、まあいわゆるドメインモデルと呼ばれるものは、そのToDoアプリで言うと、チケットの、うーん、チケットってDBに情報保存されるじゃないですか、名前とか。

うん、うん。

その名前を変えたり、あとステータスを変えたり、で、ステータスはこれとこれとこれっていうステータスを持ってるよみたいな、なんかそのへんの、なんかチケットのコア部分みたいな情報を持ってるのがドメインモデルの部分になりますね。認識合ってます?

えーっと、いやちょっと待って、えーっとね。ちょっと今追いつけなかったからもう1回お願いしていいですか。

まあチケットのステータスがToDoだよとか、ダーンがあるよみたいな情報とか、あとはなんかそのへんを更新する。更新するっていうのは難しいんですけど、オブジェクトとして更新するロジックとか。

うん、うん、うん。

書き込みは別んとこで持ってんですけどね。書き込みというか、DBに書き込むのは別ですけど。なんかそういう、このToDoアプリの中の、まあToDoアプリでやるお仕事って、まあ結局ToDo作ったりとか更新したりとか、えー、まあ要するにToDoを管理する。

うん、うん、うん。

うん。ToDoを管理するっていう本質部分を司ってるのがドメインモデルです。

To、なるほどね。ああ、むず。ToDoだからこそ逆にむずい説あるな、これ。

なんだと分かりやすいっすか。

やっぱり、やっぱ物流じゃないっすかね。

物流。

1番、あのー、本の中で物流の話が出てくるせいで全く分からないと言われているけど。

のりさん、物流好きですね。

なんだろうなあ。なんか1個ToDoのむずいなあと思ったのは、なんか現実世界にないもの、いや、まああれ、あればいいのか。現実だと何になるんだ。

まあじゃあチケット管理システムとかじゃないですか。そういう意味?

あ、いや、なんて言うんだろう、物理、物理面で言うと。

物理か。

それが物理だったとき何なんだろうっていうと、例えば紙があって、そこにタスクの内容を書いて、で、終わったらそれをもう終わったっていう状態にすると。

うん。

これができればToDoが管理できるよねと。

うん。

っていうアプリケーションであろうが現実であろうが共通してる部分がドメインなんじゃないかという。ドメインモデルなんじゃないかという。

うん、うん、うん。そういう覚え方してんすね、分かりやすいっすね。そこの交差点なんすね。まあ割とそのToDoアプリ、例えばじゃあチケット管理アプリを想像したときに、スクラムで使うような、あの、看板。看板のアプリを想像すると多分物理とアプリケーションどっちもなんか想像しやすいかなって思うんすけど。

うん、うん。

結局そのチケットの、チケットを作るとかチケットのステータスを変えるとか。で、完了したやつはまあ完了としてアーカイブしとくっていうんすか、なんかわちゃっと置いとくみたいな。

うん、うん、うん。

そのへんが、まあドメインモデルが表現するとこだよねって話ですね。

うん、うん、うん。理解しました。

で、はい。

はい。まあドメインモデルは置いといてですよ、そんな。

そうですよね。

そんなん置いといてですよね。

今回その次のステップのやつですもんね。

そうそうそうそうそう。そんなん置いといてですね。まあまあでもここまででなんとなくドメインモデル分かりましたねと。で、ちなみにちょっとこのドメイン駆動設計を始めようという本を読んでて。

はい。

親親って思った、親親じゃないな、ああそうなんだって思ったポイントなんですけど。

うん、うん。

えっとー、ONIONアーキテクチャーっていうアーキテクチャーあるじゃないですか。

はい。

あれって、あの外側から、なんかUIインフラストラクチャーテストっていうのが1番外にあって。

うん。

その中にアプリケーションサービスっつうのがあって。その内側にドメインサービスっつうのがあって。

うん。

1番内側にドメインモデルっていうのがいるんすよ。

うん。

うん。で、このドメイン駆動設計を始めようという書籍で扱っているドメインモデルというもの。

うん。

は、ONIONアーキテクチャーで言うとドメインサービスとドメインモデルっぽい。

うん、うん、うん、うん。

ので、まあちょっとONIONアーキテクチャーの予備知識がある方はちょっとそのへん混同しないように気をつけてお聞きいただけるとありがたいなと思っております。

データと振る舞い両方を含んでるよっていう。

そうですね、はい。

ことよね。

はい。で、えーと、まあドメインモデルの話、もう少ししちゃうんですけど。この書籍の中で、まあドメインモデルの部品3つありますということを言ってます。

うん、うん、うん。

で、1つが値オブジェクト。

はい。

これは前のポッドキャストでも言ったんすけど。例えばさっきのチケットで言うと、えー、まあステータス、えー、チケットステータス。

うん。

っていうものがあったときに、これあの、なんでしょうね、何も考えずに定義すると、まあストリングとかにした、した、したくなっちゃうと思うんすけど。

うん、うん。

ストリングだと、えー、まあdoing、小文字なのか大文字なのかよく分かんないとか。ワークインプログレスかもしんないし。

うん。

っていう、なんでしょうね、なんか自由度が高くなって、まあバグの原因になったりとか。あとはそのドメイン駆動設計でよく言われる、ね、共通言語使いましょうみたいなところに反する定義がされたり、されたりとかしちゃうんで。

うん、うん。

まあ基本的に値オブジェクトというものを使おうと言われてますと。

うん。

うん。で、値オブジェクトは、あのー、ストリングっていう粒度で定義するんじゃなくて、もうステータスはtodoとdoingとdoneしかないと。

うん、うん、うん。

例えばね、はい。っていうふうに定義できるのが、まあ値オブジェクトっつうやつで、それはドメインサービスの、あ、違うわ、ドメインモデルの1個の部品ですと。

うん。

うん。で、2つ目が、の部品が、まあ集約というものがあります。

うん。

で、これはチケットをデータベースで管理するときって、まあテーブル何個にも渡ると思うんですね。

うん。

えー、例えば、ステータスっていうテーブルがあんのかなとか、あとは例えば、うーんと、ちょっと機能の具合にもよるかもしんないですけど、チケットのコメントっていうテーブルが別にあるかもしんないし。サブタスクっていうのがあるかもしんないし。

うん、うん、うん。

チケットのタグみたいなのがあるかもしんないしっていう、なんかそのチケット関連のテーブルがなんか多岐に渡るようなケースってあると思うんすよ。

はい、はい、はい。

うん。で、そのチケットのなんかコメントとかなんかタグとかって、まあちょっと機能にもよるかもしんないんですけど。これなんか1個更新するときにほかのもいろいろ更新しないと不整合起きちゃうぞみたいな塊、ありそうじゃないですか。例えば、ちょっとtodoアプリだとどうするのがいいかな。チケットを削除するっていうことを考えたときに。

うん。

チケット本体のテーブルを消してもコメントだけ残っちゃまずいじゃないですか。

ああ、はい、はい、はい。

って思ったときに、チケットとチケットコメントを同時に削除したいよねっていうのって。

うん。

プログラムのコード上は、まあ1つのトランザクションでやりたいはずですと。

うん、うん。

あの、チケット消して、でもそれでデータベースコミットするんじゃなくて、えーっと、チケットのコメントも消したうえでコミットして、で、まあ一緒に消したいよねって。

うん。

いうのがあると思うんすけど。

うん。

その、なんでしょうね、その整合性をキープするために1個のまとまりとして扱いたいよねっていうまとまりを集約と言います。

うん、なるほど。

はい。で、この集約は、なんか自由に決めれちゃうんすよ、その、やろうと思えば。ただ、できるだけ小さくあるべきで。

うん、うん。

本当に整合性を保たなければいけない最小限の粒度で、えーと、集約というものを定義していきましょうねっていうのがあって。この集約が、まあ1つの、まあモデル。

うん。

の粒度になっていきます。

なるほど。え、例えばだけどさっきの例だと、えー、例えばチケットがあって、その周辺にいろんなテーブルがあってってあったじゃないですか。

はい。

でも、えーと、今回の場合で言うと。そのチケット本体とコメントだけで集約を作るっていう、そ、そんな意味ですか。

まあ、ほ、機能にもよるんすけど、例えば担当者も一緒に、担当者チケットテーブルでいっか。なんかあるかな。チケットについている、えー、ファイルとか。

はい、はい。

画像ファイルとか。

うん。

だからそのへんのテーブルがもしあったとしたら。それも1個の集約にして。

うん、うん。

で、一緒に扱えるようにしとく。

なるほど。これって、えーと、そういうなんか、なんだろう。データベースに依存してるなってすごい感じたんですけど。

はい。

えーと、基本単位ってそのデータベース基準で考えるみたいなもんなんでしたっけ。

ドメイン、業務基準ですね。

業務基準。

はい。

うん。

だから、なんかちょっと分かりづらい、いい例あるかな。なんかテーブルとかはもう関係なく、なんか例えばこのポッドキャストで言うと。

うん、うん、うん。

もうかいちがこのポッドキャストメンバーから削除されたときに、かいちが出てるエピソード全部消さなきゃいけないみたいなちょっとビジネス要件があったときに。

うん。

いや、それどうなんだろうな。非同期的になりそうだな、すいません。

え?

同期的に消したいものは集約すべきで、非同期は別に集約しなくていいんすよね。

うーん。

なんかあるかな。まあその、同期的にやりたいものはまとめるべきですね。で、なぜならその同期的にやる必要があるってことは、1つのビジネス要件として。

うん、うん。

ひとまとめで扱ってるはずで、そのビジネス要件の中でひとまとめに扱うものは集めましょうねっていう概念。なんで今ちょっとチケットの話をしててチケットしか登場人物がなかったんでちょっと、なんだ、なんかデータベースとその、なに、こ、こ、子テーブルっていうのかな。

うん、うん。

の話に終始しちゃったんですけど。

うん。

そ、そうじゃなくてもありうるって言いたかったです。

なるほどね。ビュッフェで言うと。

ほう。

あれだよね、ソーセージしなぎれになったらポトフもソーセージも出せなくなるよってことっすか。

ちょっとこれはなしのほうがいいかもしれないな。

どういうことなんだ。いやまあポトフにソーセージが入ってるからですよね。

うん。

それはちょっと違うかもしれないな。

これはちょっとなしのほうがいいかもしれない。

はい。

今のを聞いて幸せになる人がいなさそうだ。

ほんとっすよね。だってね、ポトフ出てくんのかなと思ってた人もちょっとね、今残念な気持ちになったんで。

そうだよね。

うん。

まあ、で、すいません。で、まあ集約の話ちょっと触れて、まあこれも別にメインじゃないんで。

うん、うん。

で、えー、最後の部品が業務サービス。

業務サービス。

はい。

はい。

えーっと、これはあのー、集約とか値オブジェクトで表現できない業務ロジックがあったり、あとは複数の集約にまたがるような業務ロジックが見つかったら業務サービスとして記述しましょうというふうなことが書いてて。

うん。

まあ1つの集約で扱いきれない、だからこれやってこれやってっていうのが1連の作業である場合は業務サービスとして。

うん。

定義してやりましょうね。まあこれがなんかいわゆるドメインサービス、えっとONIONアーキテクチャーでいうドメインサービスにあたるところ。

うん。

うん。になります。で、えー、もう次いきますね。

はい。

はい。で、ここであの僕がちょっとあんまり今まで学んでこなかったところで紹介したいのがイベント履歴式ドメインモデルというものになります。

うん、うん。

で、今まで言ってたその散々言ってたドメインモデル、さっきのチケットの話とかもそうなんですけど。あれって今の状態を管理するもんなんすよ。

うん。

うん。

うん。

で、え、一方で今の状態しか管理しないと深い洞察って得られないんですよね。

ほう。

ビジネス要件的に。例えばさっきのtodoアプリで言うと。

うん。

まあ、何時何分に、こ、えーと、doingになりました。何時何分にdoneになりました。よーし、終わった、よかったねって終わっちゃうんすけど。

うん、うん、うん。

これがですね、イベント履歴式ドメインモデルを使うと、あー今週のこの人の作業はこのぐらいの時間で終わってらねえなのかとか。あとは今週チームのチケット消化具合はこうなってるね、先週に比べてこのぐらい上がったねとか。

うん。

なんかそういうチケットのステータスの履歴とかを管理できるようになるんで、そのデータを分析することによってなんか洞察が得れるようになると。

うーん。ほう。

で、これってまあチケット管理だから、まあそういう話はしてたんすけど。

うん。

そういう話というか、まあこのぐらいで済むんですけど。

うん。

実際のサービスに考えると、なんかユーザーの動線が見えてくるって言うんすか。ユーザーがこういう動きをしてとか。

うん、うん、うん。

まあそういうのが見えてくるようになるので、あとはまあ営業の管理システムだったらその、この営業の、なに、サービス、なんて言うんだ、えっと、発注が来てそれを納品するまでのトレースができたりとか。

うん、うん。

なんなら監査ログとして取れるとか。

うん。

まあなんかそういう、まあ使い道が出てきますっていうのがまあイベント履歴式ドメ、ドメインモデルになります。

ふーん。うーん、なるほど。ちょっとなんかまだよく分かってないのは、なんか普通のドメインモデルだったときに、なんかなぜそれができないのかがよく分かってないかもしれない。

で、普通のドメインモデルだと、あのー、まあち、データベースのテーブルの持ち方として、まあ普通にやろうと思うと1チケット1レコードとして管理されるじゃないですか。

うん。

まあそれを、り、イベント履歴式だと、もう更新しても新規レコードをついて、追加してくようなデータの取り方になります。

なるほど。いやなんかこれってその、で、データベース設計の話とかで言っちゃうとさ、例えばだけど、あのー、まあこれがいい悪いはさておき、例えばそのー、todoの変更履歴テーブルみたいなやつ作って。

うん。

IDに対して、えー、どのタイミングで何の操作がありましたみたいなやつを記録してれば、えーと、追えるんじゃないかなと思ってて。

うん。

この実装したらもうそれはイベント履歴式になるってことっすか。

そうですね。

あ、それは...

ただ一方で。

はい、うん。

今のりさんが言ったやつって。

うん。

テーブル数倍になるじゃないですか。

うん、うん、うん、うん。

で、まあなんか、まあこういうふうなやり方があるよって紹介されてたのがまあ今私が紹介しようとしてる章で。

うん、うん。

で、まあなんかそこで具体的にどうやってやるパターンがあるよって書かれたか、いたかで言うと、まあこれってあの、リレーショナルデータベースでやるかNoSQLでやるかも、でもやり方が変わりますと。

うん。

で、リレーショナルデータベースでやる場合は、まああの、書かれてたのはそののりさんの言うような履歴テーブルを用意するっていうよりは、どっちかっていうともともとあるテーブルの中で、えーと、1つのチケットに対してレコード何個も置いとく。

うん。

ようなパターンが紹介されてましたね。

うん、うん、うん。

か、もしくはPostgreSQL。

うん。

に、えーっと、JSON扱うデータ型があって。

うん、うん。

で、そのJSON扱うデータ型の中に、過去の履歴JSONで詰め込んでいくっていう。

うん。

まあその2パターンが紹介されてました。

なるほど。

なんで多分今後でもおそらくJSONでぽこぽこぽこ入れてくんだろうなっていう感じだったりします。

うーん。こ、これはあれなのか、データモデルの話なのかな。なんかレイヤーが分かってないのかもしれない、もしかしたら。

データモデルの話なのかなっていうのは。

うーん。いや、なんて言うんだろうな。こうドメインモデルを考えたときに。

はい。はい。

あのー、どっちかっていうとデータベースがどうこうよりもコードのイメージが出てくるんですけど。

あ、そうだと思いますよ。ドメインモデルの中で。

うん。

そういうふうに管理するようにドメインモデルを実装するイメージですね。

うーん、ああ、そういうことか。だからそういう、り、変更履歴を持ってるドメインモデルのことをイベント履歴式ドメインモデルと言っている。

あ、イエスです、はい。

ああ、そういうことか。あ、じゃあ大丈夫です、はい。

はい。で、まあなんで、なんて言うんでしょうね、やることはシンプルなんすけど。

うん。

これ結構めんどくさくて。

うん、うん。

えー、なぜならそのチケットの中のステータスが更新されるだけでも、なんでしょうね、全体分の、まあ履歴を取っとかなきゃいけないっていうんですか。

うん。うーん。

し。あとはまあなんか新たにバージョンっていうカラムを追加して。で、それで、まあ時系列だけでも見れるかもしんないですけど、なんだろうな、なんか古い順に並べられるようにしてたりとかしておかなきゃいけないよねとか。まあそのあたりいろいろめんどくさいとこあるんすけど。

うん。

まあでもなんかこういう選択肢があるよっていうのはちょっと僕の中で持っときたほうがいいかなと思ったんで。

うん。

まあ一旦紹介しましたと。

うん。

でちょっと残り時間のところで、このイベント履歴式ドメインモデルの懸念みたいなところのちょっとお話できればなと思うんすけど。

はい。

これって、まあ性能問題ないのというところが気になります。

うん、うん。

なぜなら、なんか今まで1個、1個持っときゃいいのが、なんかバージョンいっぱい持たなきゃいけなくなるんで、レコードか、レコード数か、レコード単体の量が増えますと。

うん。

でこれはあの、書籍の中でもまあ影響はまああることもあるよという書き方がされてて。まあ一方でイベント履歴がそんな大したことないんだったらそんなに影響はないよと。まあ例えば100未満とか。1万とかになるなら影響出るけどねみたいな話はされてました。

うん、うん、うん。

でまあそこはあの要件に従って性能テストやってまあ調べてみてねっていうのもあるんすけど。じゃあもし、えー履歴1万とか持たなきゃいけないときはどうする手があるんだと。いうところでちょっと紹介されてたのが、スナップショットキャッシュを作ろうっていう話が出てました。

うん。

でこれ何をするかというとですね、まあもともとそのデータベースのレコード1個1個で各バージョンを管理するようにすると、えー過去のバージョン全部取ってこようと思ったらテーブルスキャンして、でそれであの条件あったやつをいっぱい取ってきて、で並び替えて返すみたいなことをしなきゃいけなくなって。まあちょっとパフォーマンスに影響出るんすけど。

うん。

その、なんだ、1連のバージョン取ってきて並べて置いとくっていうのをもう別のプロセス、アプリにやらしちゃって。でその取得した結果を、まあキャッシュストアに入れときましょうねっていう。

うん、うん、うん。

なんでまあ非同期的に、まあ定期的に更新しといて、で実際にアプリが取ってくんのはそのスナップショットのキャッシュストア。

うん。

から取ってくるっていうようなデザインにすると、えーパフォーマンスもまあ割と良くなるぜ。ただ、これ結構複雑だし、ここまでするんだったら、まあそもそも設計見直すのもいいんじゃないのっていうような書き方はされてたんですけど。

うん、うん、うん。

まあこれも、まあアーキテクチャ検討の選択肢として、まあおもしろいというか、あ、そういう手もあるんだなっていうので勉強になったので紹介させていただきました。

なるほどね。

うん。

はい。

ずっと具体例を考えてたんですけど。

はい。

健康診断とかどうすか。会社が社員の健康診断を管理していて、毎年時期が来たらそれぞれ健康診断を消させる。

バージョンなんだ。

うん。

30歳の結婚、けん、健康診断バージョン30で。

そう、そう。

登録される。

バージョン30からボリューム選べるよみたいな。

うん。

うん。

なるほどね。アップデートが入りました。

まあ実際あの、なんでしょう、僕もこのtodoアプリの例を出したのはなんか適当ではなくて、Jiraとかがそうなんすよね。

うん、うん。

履歴取れるようになってて。まあそのチームのアクティビティとかをつい、追跡するために取れるんすけど、はい、っていうので出してみてました。で、えーちょっとそろそろ時間も来てるので、バツ閉めようかなと思ってんすけど。はい。今日はあのドメイン、ん？イベント履歴式ドメインモデルっつうのをちょっと紹介したんですけど。まあこれはあの、なんでしょうね、ドメイン駆動設計の概念の中での、えーすごく狭い分野かつやや応用的っていうすごいニッチなとこ攻めてみたんですが。

うん、うん、うん。

まあなんか今後のね、設計の選択肢の1つというか、こういう考え方あるのかなっていうのがおもしろかったと思うので、個人的にはおもしろかったので、またなんかあったら紹介させていただきます。

はい、ありがとうございます。

ありがとうございます。

では閉めます。ハッシュタグ、ひまじんプログラマーでSNSのXでフィードバックを募集してますので、本日のエピソードの感想、なんでもありましたらお願いいたします。

お願いします。

待ってます。

えーあとは、ポッドキャストのエピソード説明欄からGoogleフォームで番組の要望、感想、質問お待ちしてます。チャンネル説明欄からSlack、オンラインコミュニティ、ひまプロ談話室の参加申し込みフォームもございますので、そちらも、えー刺激受けたいよという方、どしどしご参加お願いいたします。

ちょくちょくイベントもやってます。

うん、もうすぐLT回。

確かに。

最後に各種ポッドキャストプラットフォームのフォロー、高評価もお願いしまーす。

お願いしますー。

お願いしまーす。

はい、それではまた次回。

バイバイ。

バイバイ。

あなたが落としたのはこの金のサーバーですか。それとも銀のサーバーですか。

いいえ、私が落としたのは普通のウェブサーバーです。すみません。

あなたは正直者ですね。全部のサーバーを上げましょう。

正直者のエンジニアは不可分散ができるようになりました。それを見ていた欲張りな男がサーバーを落としました。

あなたが落としたのはこの金のサーバーですか。

へい、その金のサーバーを落としました。

どうやらあなたは嘘つきのようです。

そう言って女神は帰っていきました。欲張りな男は復旧できないサーバーの前でわんわん泣いていました。

サーバーを落としたくないあなたへ、ひまじんプログラマーの週末エンジニアリングレッスン。