Domain modelling made functional Chapter 6, Chapter 7を読む

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

6章では集約などの一貫性をどう表すか、を重点に置いて話を進めていっている。ここでも型として表現していくことを徹底している。例えばビジネスルール上で「顧客はemailか住所を持っていなければならない」とした時に、どう表現するか? この本の回答はこうだ。

  • emailのみの情報を表現する型
  • 住所のみの情報を表現する型
  • emailと住所の情報を表現する型

これらの型の'OR' Typeが顧客が持つ情報であるとしている。こうすることによって、ドメイン上でありえない状態に陥ることがなくなる。型で表現することによって、そもそもillegalなことを表現させなくするという観点は非常に面白いし、自分の頭からは抜け落ちていた観点だったと気付かされた。

またDDDの文脈でよく出てくる集約の一貫性の話、単一の集約や複数の集約間の整合性はどうするかなども書かれているが、やはり基本として「1集約に1トランザクション」「結果整合性」という話になる。この部分はまあそうだよねという気持ち。

7章はワークフローをパイプライン処理できるよう個々の関数に落とし込んでいく。入力であるCommandをGenericsを用いて表現したり、MQに単一のCommandだけでなく複数のCommandが入る場合は型としてどう表現するかなど、見所は多い。が、ここではこれまで定義してきたそれぞれのOrderを状態として捉える、UnvalidatedOrderが処理されることでValidatedOrderになりまたそれが処理されPriceOrderになる、一連の流れを状態の変化として考えることが重要な点だろう。型によってState Machineを表現することによって、抜け漏れなくある状態である動作を行うことができるようになる。実際にどでかい状態遷移図で悩まされたことのある自分にとっては、ありがたさがよくわかった。

後半では、副作用を表現していったり長期間にわたるワークフロー*1についても書かれている。副作用を型として表現する話は過去にScalaMatsuriで聞いていたのですんなりと納得できた。本書中の例としても途中のValidationを行う関数がリモートサービスを呼び出しているので、それを呼び出してる関数もreturnとしてはAsyncResultにならないといけない、とわかりやすい。Sagasは最初さらっと読んでいたが、今考えてみればAkkaなんかを使う局面と考えても良さそうだ。

ここまでで、一旦モデリングは終わり。8章からは実装の話に移る。

*1:Sagasと呼ばれる

Alt MacBook Pro充電環境を揃える

cheero USB-C PD Charger 60W (White + Silver)

cheero USB-C PD Charger 60W (White + Silver)

CheeroのUSB-C PD充電アダプターが新しく出て、若干安くなってるのに気がついた。

たまーに会社のMacBook Proを持ち帰って仕事したりすることもあるけど、アダプタ類を持ち歩くのもめんどくさいなーと思ったりするので、この機会にサクッとUSB-CケーブルとUSB-Cハブも買っておくことにした。

届いたので動作チェックしてみたが、今のところ問題なし。持ち歩くこと考えると、こっちの方が楽かもしれない。

Domain modelling made functional Chapter 4, Chapter 5 を読む

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

ちょっと開いたけど、読んでいる。Chapter 4がF#での型システムの話、そしてChapter 5がそれを踏まえてOrderTakingSystemを型で表していくという流れ。

DDDでモデリングしていった結果、Value ObjectやEntity、Aggregateを発見していくけど、それらを型として定義してWorkflowをそれらの型の変換という形に落とし込んでいく。型として表す、それ自体はDDDにおいて大事な話だと思うが、Workflowを型として表していくのは実はしっくりくるのではないかと思った。実際にValue ObjectやEntityに属しないけど必要なビジネスロジックなどは存在するので、それらはServiceとして表したりするのだけど、データとしての型とそれらを変換する関数として定義するとそういう違いもなくなるなと。個人的にはChapter3あたりと違って、腑に落ちる内容が多かったかな。

読書会内ではOR typeをScalaで表現するとなると、case classが頻出してちょっと記述がめんどいなどの話や、AggregateであるOrderに含まれるEntityのIDのみを持つのかそのEntity自体を持つのか、その判断はどうやって決めるのかなどが上がっていた。Aggregateに他のEntityそのものを持たせるかは、基本的に疎結合強凝縮を意識してモデリングしていけばいいのかなと考えていて、今回の例だとそのドメイン上で扱うにはOrderからOrderLineのリストが辿れるようにしておく、CustomerはIDのみ持つは一つの解かな。詳細でRDBに保存するにしても、ドメイン上ではそれが置いておくのが吉となりそう。もちろん実装上OrderLineが膨大に持つことになってメモリを圧迫するとかなってしまうと、IDのリストを持つとか考えれば良さそうだが。

「【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践」を読んだ

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

最近他チームの手伝いでテスト作ったりしてるんだけど、今一度テストってどうやるんだけっけ?と思い購入。月一で書籍購入を会社でやってくれるのは本当にありがたい。

同値テスト、境界値、組み合わせテストなど、個々のテストについて作成の仕方を解説したり、もっと大枠の話としてテスト計画やテストの設計をどうしていくかなどが網羅的に書かれているなと感じた。内容的には知っていることも多く、忘れていたことをちゃんと呼び覚ましてくれたというところが大きいが、初めてテストに携わる人なんかはこれを読んで勉強するのも良いかと思う。特に組み合わせテストでのテスト項目の削減方法はきっちり知っておくといい。全ての組み合わせでテストするのは到底現実的でないので、いい落とし所を作るためにどうするか学べる。またこういうところはTDDやるときに、仕様からどういう値がありうるかなとか考えるときに役立つかな。

ただ記載のある内容は基本的に真面目にウォーターフォール開発でのテストを念頭に置いてるものなので、テスト計画のところはまあそういうこともあるよねぐらいの感覚で読んでおいたほうがいいかもしれない。現実的には無理くりやらないといけないこともあったりするのだ……うっ頭が……とはいえ、前々職で作っていたテストドキュメントなどはこういうのを元にして作ってるんだなという気づきがあった。以前読んだメルカリでのテスト管理ツールの選定に出てきたツールたちもこの辺りを念頭においたりしてるのだろうか。

tech.mercari.com

あと、アジャイル的にやっているところとかだと、本に書いてあるように設計書が細かく分かれているとかない場合もあるから、そういうときにどうなるかなーというのは気になる。もちろんソフトウェアが満たさなければならない要求があるのだから、それをチェックするためのテストがあればいいのだけど必ずしも本書通りの形にはならなそう。継続したテスト、テストの自動化、などなど最近話題のところもあるけど、本書では範囲に入っていない。以下のリンクのように探索的テストが必要な場合もあるだろう。

codezine.jp

ただテストする上での知識として何が必要かは、必要十分に詰まっていたと思う。割とさっくり読めるのでテストの手始めに読むのが良いと思った。

ネタバレになりそうな気もするゴジラ キングオブモンスターズ感想

godzilla-movie.jp

うまいこと時間が調整できたので、初日にさっさと見てきた。予告やちらほら流れてくるvsシリーズっぽいというお話に少し胸を踊らせて、19時からの回に。

結論からいうと、これは売れそうだなぁと思った。ハリウッドが作った大娯楽映画。派手なシーンも多く、あのキングギドララドンモスラがこれでもかと動きまくって見せ場も多い。音楽も伊福部昭のあのテーマを盛り込みつつ、面白い仕上がり。監督自身がおそらくほとんどのゴジラ映画は見てるんだろうなぁと思えるオマージュの数々、特撮好きがこぞってどれが元ネタか探そうとするだろう。話のネタとしては申し分ない。これを見るにあたって予習はいらないと思うが、もし数々のオマージュが何かを知っておきたいのであれば、この辺を最低限押さえておくといいんじゃないだろうか。

ゴジラ

ゴジラ

ゴジラVSデストロイア

ゴジラVSデストロイア

ゴジラVSメカゴジラ

ゴジラVSメカゴジラ

怪獣大戦争

怪獣大戦争

怪獣総進撃

怪獣総進撃

空の大怪獣 ラドン

空の大怪獣 ラドン

モスラ(1961)

モスラ(1961)

ストーリーもまあこういう荒唐無稽さというのは頭を空っぽにしてみる映画としては気にしなくてもいい、と振り切った感じになってるので気にしない人は気にしなさそう。マッドサイエンティストっぽい人たちはそれこそ初代の芹沢博士とか、メカゴジラの逆襲の真船博士とかもいたわけだし、復讐に燃える人と言えばvsスペースゴジラの結城さん*1とかもいたりあまり気にならず。

オルカの扱いなんかは怪獣総進撃の怪獣ランドとか怪獣大戦争のあれとかに近いのかなーとか。それこそ各地に怪獣が出現して暴れ出すというところなんかは、まんま怪獣総進撃でキラアク星人に操られた怪獣が世界各地に現れて破壊を尽くすというところに他ならず。そういや声に反応するネタだと84年のゴジラもそんなんだったなーとか。流石にモナーク環境テロリストそれぞれのザルさはなんなんだろうと思ったりしましたが、モナークがヘリで基地に着陸するところとか、完全にvsメカゴジラだしそういうメカ描写も面白いところはあった。もっとやるなら東宝特撮らしくメーサーとかああいうの出してくれてもいいのよ。

関西に住まうvsシリーズドンピシャ世代としてはエンディングのGodzillaのカバーに嬉しくもあったりした。


読売TV「ゴジラ復活作戦第2号」タイトル


読売TV「ゴジラ復活作戦」タイトル

vsシリーズっぽいというは確かにそうかと思える。2014年のギャレゴジやシン・ゴジラとは違う手触りでエンタメとしてのゴジラ映画であり、昭和のシリーズやvsシリーズに近い。いわゆる怪獣プロレスを求めている層だとドンピシャなんじゃないだろうか。


とかつらつら書いてきたけど、個人的には、最後まで映画にのれなかった。自分自身vsシリーズドンピシャで、昭和シリーズも全部見てきた。要素要素で見ると好きなものもたくさんあり、そういう細かいところをつつく楽しみ方もできてたし、南極でのギドラ登場〜ゴジラとのバトルシーンやラドンソニックブームなんかもすごかった。

そう映像はすごいものがあった。

すごかったけど、なんか自分にはグッと来なかった。

何がしっくりきてないんだろう? 見終わってから考えてみたのだが、映画として没入しずらい構成に感じた。序盤の方はそうでもなかったのだが、南極のバトルあたりから全体的な流れを感じずとりあえず見せたいシーンを繋げまくったという印象が残っている。また人が足元にいる中、怪獣たちのバトルが繰り広げられる箇所がやたらと多かった。おそらく物事がシームレスに繋がってるということなんだろうけど、怪獣の取っ組み合いをちゃんと見たいのに度々視点が人の方にいってしまうので、途中で意識が途切れてしまった。あとやたらカメラが近いので、もうちょっと空間を持たせて作ってほしかった。

役者さんたちもいいキャラしてるなーというのが多くていいんだけど、結構な脱落者が出てしまって色々もったいないなーと思ってしまう。そこらへん文化の違いなのかもしれないけど、芹沢博士の重みが薄らいでしまってなんだかなーという気持ちです。

結局のところ、映画としての緩急を感じられなかったのが、自分がのれなかったところなのかなと思う。良くも悪くもずっと高カロリーの油物が立て続けにくる映画。そこに自分はさっぱりとしたサラダ類などがほしかった。そんな気持ちです。


ただ来年にはコングとのマッチが控えていて、果たしてどうなるのかという期待は今から持っている。実際に今回のゴジラはかなり評判いいみたいだし、今後も作られていくことになるかもしれない。そうやって火を絶やさないようにはしてほしいと思う。多分見にいっている。

二週間ぶりにまた風邪ひきそう

昨日人混み行ったのがあかんかったか……悲しみ。念を飛ばしておく。

【第3類医薬品】南天のど飴U 54錠

【第3類医薬品】南天のど飴U 54錠

THE IDOLM@STER MILLION THE@TER GENERATION 04 (特典なし)

THE IDOLM@STER MILLION THE@TER GENERATION 04 (特典なし)