Booklog - Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう

冒頭を読んだだけ。なんとなく丁寧な印象を受けた。

2024-08-19, read count: 1, page: vi ~ 5

DDD の紹介。イベントストーミングの途中。 先をざっと見た感じ第 1 部はモデリングに徹するみたいなのでやはり丁寧な印象。

2024-08-20, read count: 1, page: 6 ~ 14

イベントストーミング終わった。 原著者が Railway Oriented の人なのもあってワークフローを中心にしてる印象で、モデリングにもパイプラインのメタファーが基礎にありそう(勘)。 次モデリングのステップの理解を深めてく感じ。

2024-08-21, read count: 1, page: 15 ~ 29

一通りモデリングのステップをなぞった。 わたしの DDD の理解はかなり浅いが、 Evans に始まりそれいいなと思った人々の我流をまとめてる広義にそう呼んでる認識なので、この dmmf のそれも FP でやるならこうよな、という感じを受けてる。パイプラインのメタファーは好きなのでいいけど。

2024-08-22, read count: 1, page: 30 ~ 41

FP 的にコンテキストの構造とかコードの構造とかこうするよなという話。 必要になるまで MSA やらず monolith よなというのはまとも。

2024-08-23, read count: 1, page: 42 ~ 53

定義したドメインをモデルにするための F# のレシピ。 単純型と言う名で single case DU 使ったりしてるがデータ量によっては遅いし、氏の blog であるよな Unit of Measure 使うトコじゃないかなという気はする。

2024-08-24, read count: 1, page: 54 ~ 71

レシピをべースにモデル化していく。 パフォ問題に対するための Unit of Measure が出て来ず Struct とコレクションの単純型だけか。 数値しか使えんし触れないのかな。

2024-08-25, read count: 1, page: 72 ~ 83

レシピをべースにモデル化していく続き。 値オブジェクト・エンティティ・集約はここで例示しつつ触れられた。 NoEquality を使う辺り .NET と一緒に使うことを考えなければその方が simple で楽なのはわかる。 でもいつまでどこまで .NET から離れれるかよな。資産を使った方が楽なものもあるし。

2024-08-26, read count: 1, page: 83 ~ 97

型システムを利用してドメインに不正な値が入らないようにする等。 private construct のくだりはまあわかるが match 使えないの痛いのとテストも書きにくくなるのでそこはあまり好かん。 整合性の部分はまあせやろなという感じ。 整合性を保たねばならないトランザクション自体エンティティでは？というのはそうかも知れん。

2024-08-27, read count: 1, page: 98 ~ 112

ワークフローをパイプラインに落とし込む。 サブステップをパイプ処理に当てはめて in/out の型も作る。型しか出てきてない。 依存関係は高階関数でやるのは FP ならそうよなという感じ。

2024-08-28, read count: 1, page: 113 ~ 131

型だけで設計したので、最終的に関数合成しないのかなとかあんまピンとこないところもある。 Saga という言葉は知らなかった。 長時間稼働するやつは DDD 関係なく必然的にそうなるよなという感じ。

2024-08-29, read count: 1, page: 131 ~ 138

FP の話。パイプラインでドメインを繋いぎた本なので後半に進む前にどうしても話したかったんやろなと思った。 ゼロ除算を愚直にサポートするならわたしは愚直に Either(Result) を使うかなと思ったが、 違った。 引数用に 0 存在しない型を作っとくみたい。DDD では多分キレイなドメインの世界ではエラーなぞ存在せぬという意思表示なんやろな。 どこで match で切り分けるかの違いだけなんで、そういう流派という理解。

2024-08-30, read count: 1, page: 139 ~ 154

パイプラインでドメインを繋ぐ。 例だからか知らんが failwith 使ってるので、好みじゃない。バキバキ副作用やん。更に失敗する可能性のある関数と示せないのがな。 不安になったので先の章を見たら computation で Result 使いつつどうにかする話が出てそうなので、ちょっと安心した。 エラーをどう扱うかも設計時から考えてほしかったな。

2024-08-31, read count: 1, page: 155 ~ 166

FP のテクニックでドメインのパイプラインを繋ぎ終えた。 lifting してて良い。 例外避けたいから次章出直すとのこと。Expecto と FsCheck は試せてないからそのうちやりたい(と言いつつ随分経った)。 部分適用による依存性の注入はわたしもよくやるのだけど、多過ぎると面倒なので Record に詰め込むことをしている。 この章のアプローチでは引数に羅列しているのが、どうなんだろ。 この本でモナドでの実装は詳細に触れないようなので自分で考えな。

2024-09-01, read count: 1, page: 167 ~ 187

FP 的エラーの扱い。 ようやく railway oriented. 明示的エラーといえば Java の検査例外を思い出す。 bind, map からの独自 computation って流れだがわたしはあんま使いこなせてないからなじませたいな。 結局のところエラーの扱いがクリーン()なコードを汚すからその複雑性を DSL に寄せるという理解。 それ自体は好きだが Go のように愚直にエラー処理書くのもわかりやすいといえばそうやと思うので流派かなあ。

2024-09-02, read count: 1, page: 188 ~ 218

シリアライズは地道に手で書く感じ。キレイな世界に出入りするための通過儀礼みたいなもんか。 高級なモデルから平易なデータ構造に落とすため single case union すらもシリアライズ用の DTO に丁寧にマッピングする。

2024-09-03, read count: 1, page: 219 ~ 239

永続化。CQS と CQRS は違うと。モデル自体が分かれてるのが CQRS でいいかな。 イベントソーシングのも当然触れられてるが、十分に説明できないとスルーされる。

2024-09-04, read count: 1, page: 240 ~ 251

RDB への永続化。 少しテーブル設計に触れてるけど、元々キレイな世界とその他で分けてるのだし、テーブル設計は RDB の事情に合わせてやればいい。 ORM 使わないのはわたしの好みなので良い。補償トランザクションは知ららなかったので調べておく。

2024-09-05, read count: 1, page: 252 ~ 266

設計を更新するのに型駆動でコンパイルエラー活用してやるって話。 このときにはじめに作ったドメイン文書には触れないんかー。これで本は終わり。 本を通して、 computation や active pattern の F# 機能を活用することあれど、データと処理が分割された FP の特徴を活かして静的型駆動でドメインを表現するテクニックの話だったと理解した。 個人的に気になった F# でのパフォの改善等は触れられてない(link は多少あるか)ので自分でやれってことやろな。

2024-09-06, read count: 1, page: 267 ~ 287