正確には「関数型ドメインモデリング ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう の見本誌をいただいたので読んだ」ということになる。
訳者の猪俣さまより見本誌を提供いただきました。ありがとうございます。（発売少し前にいただいたのだけど結局これを書いてるのが発売後になっていて申し訳ない）
以下に書評というか感想を書きます。
おまえは誰
まず、どういう立場の人間が読んだのかというのを明らかにしておく。
株式会社はてなというところでWebアプリケーションを書いている。ここ数年はGo + GraphQL + Next.jsみたいな感じのサービスを扱っている。
関数型言語については数年間Scalaを書いていたのでふんわりと認識がある、くらい。DDDについてもそれ自体はふんわりと認識があるくらい。中の個別のプラクティスについては意識的ないし無意識的に扱っていることも多かろう。
実はしばらく前から社内で本書の原著である "Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#" の読書会が始まっていて、その兼ね合いで途中までは原著で読んでいた。ちなみに担当した部分は2章の Understanding the Domain でした。
雑なサマリー
先にサマリーっぽいことを書いておく。
- OOPベース*でない*方法でドメイン駆動設計を実現する手法として自分の手札に加えられると有益だろう
- ピュアに関数型言語でなくても考え方や一部を取り入れられる可能性は高いだろう
- この設計こそが全ての問題を解決する！という万能感を得られる物ではない
- 一見気になるようなトピックは理想化されたケーススタディでよくカバーされているが、実践的とまでは届かないだろう
- 「関数型プログラミングでドメイン駆動設計をモデリングする」の理解において F# を事前に知っている必要はない
- 関数型プログラミング自体が全く分からないと話は変わるかも？
- F# の本としては自分に学がないのであまり響かなかった
- 悪かったと言いたいのではなく、判断できる材料を持ち得なかった
- F# ってのはこういう感じなのか〜と思ったくらい
- 日本語で読めることは大変ありがたく、今回の邦訳は価値が高い
- 非英語話者における DDD について考える契機ともなって面白かった
そしてサマリーを書くと総評っぽいことも導けて、これはサマリーの1行目がほぼ相当するんだけど、オブジェクト指向でないパラダイム (= 関数型プログラミング) でドメイン駆動設計を実現する手法として良いインプットになる内容だった。現代のプログラミング言語の多くには関数型のパラダイムを多かれ少なかれ含むわけで、関数型色の強いプログラムを書いている人でなくとも一部のエッセンスや考え方を取り入れる余地は十分あるように思う。
他方で、本書の内容だけから関数型プログラミングによるドメインモデリングで実際のソフトウェア開発を直ちに始められるという物でもなくて、「立ち向かおう」というタイトルはそういう温度感っぽい。
以下、細かい話をもうちょっと書くけど、多分ここで読むのやめてもらっても問題ないです。電子書籍は達人出版会から出る予定とのことでした（これを書いた 7/2 時点では未発売）。
全体感
すごくざっくり言うと、本書の提唱している手法は、代数的データ型によってドメインモデルを精緻にモデリングしようということと、ワークフローが F# のコードにスマートに転写できるよということに大別されるのかなと思う。（あとは実用的には「I/Oを端に追いやる」とか？）
そのあたりの考え方を脳にインストールするのには手頃なボリューム感だったと思う。
また、第1部で（必ずしも関数型に依らない）ドメインモデリング手法についてざっと触れられているのも良かった。これ自体でDDDについてマスターできる！という物では全然ないものの、モデリングプロセスについて一通りの理解を得るのに良さそうだった。
一方、本書で取り上げられるのは考え方の提示であるとか理想的なケーススタディという性質が強くて、実際はこうはうまくいかないでしょうが……と思うところは多かった。本のタイトル的にもそこまで期待して読む人は少ないと思うけど、この本を読んで「ええやん！」となった人が現実のソフトウェアに適用しようとするといろんなことが待っているのは想像に難くない。
id:motemenさん（会社でこの本を読むぞ！と言い始めたCTOでもある）のこれにも同意。
本では、いきなり F# を書くのではなくてドメインにおける状態を擬似コード的に表してみるとアラ不思議、F# のコードにそのまま変換できる、というストーリーになっているけれどそこまでうまくいくのかは疑問。
Domain Modeling Made Functional を読んだ - 詩と創作・思索のひろば
代数的データ型
代数的データ型で表現するのはいっけん妥当そうに思える。ドメインロジックを記述する際に入力の事前条件などが型で強く制約されていると嬉しいというのは、静的型のあるコードをある程度書いたことがあれば想像可能な喜びだと思う。
（普段 Go を書いていると、Go でこういう Union 的な型を扱うのがそうスマートではないことを想像して渋い気持ちになったりもするのだけど、まあそれはそれとする……）
一方で、こういうドメインモデル（とワークフロー）の作り方をしたとき、ドメインロジックがワークフローの中に手続き的に記述される誘惑が非常に強いと思っていて、つまりこれはドメインモデル貧血症を誘発する構造じゃないか？というのは気になる。本の中で取り上げられるような規模であれば問題ないだろうけど、一つ一つのコンテキストが大きくなっていくと問題になるんじゃないかと直感的には気になる。もしかすると関数型プログラミングの有識者の中では解決されていたりするんでしょうか？
F#
F#のことはほとんど知らないまま読んで、結局ほとんど知らないまま終わってしまった！！！
F#固有の実装テクニックについては、自分の過去に触れた関数型パラダイムの言語のことを思い浮かべながら読み流してしまったけど、「関数型ドメインモデリングを知る」というのには困らなさそうだった。
F#のコード自体は擬似コード的に読み下すぶんには特に困らないが、最初から最後まで見慣れないままだったので脳にF#のパーサーが構築されないままだった気もする。
もしF#について学びたいという動機があるのなら別にF#を学ぶ過程は必要そう、まで書いてからそれはそうかとも思った。
邦訳
邦訳についての感想は、まず何より「日本語で読めて最高！」ということになる。原著もソフトウェア技術書として難しい英語では全然ないのだけれど、日本語だと当然スルスル読めて、読書会の自分の担当に間に合っていたらどれだけ楽だったか、という気持ちにもなった。
翻訳は読みやすく、（訳者まえがきでも言及されているように）意訳が少なく、また訳語の選択もおおむね違和感なかったように思う。（原著を素直に訳したら出てこなかったのは理解できるものの、「代数的データ型」という単語は言及されていても良かったように思うが……）
全体として、英語で書かれた原著に対応する邦訳として必要十分な品質の翻訳だったと思う。
ただ、これは翻訳の責任ではないというのは前置きするけれど、本書に限らずDDDにおける「ユビキタス言語を定めてドメインエキスパートと共有しよう」であるとか、「疑似ソースコード的に記載したワークフローは直接ドメインエキスパートが読むことができる」といった主張について、日本語で書かれた本の中に出てくるユビキタス言語や疑似ソースコードが英語で書かれていると、どうしても「それはドメインエキスパートと共有できてなくない？」という気持ちになるのは禁じ得なかった。。
この話は多分世の中で既に無限に話されている話題なので深入りはしないけど、現実には多くの場合ドメインエキスパートとは日本語で話してエンジニアは英語の識別子で書くとなるんだろうけど、そうしてしまうと例えば本書 5.9.1 でいう以下のような主張を読んだときにややしらけてしまう、ということはあった。。。
あなたが開発者ではない人だと想像してみてください。このコードをドキュメントとして理解するた めには、何を学ばなければならないでしょうか。単純型(単一ケースの共用体)、AND 型(中かっこつ きのレコード)、OR 型(縦棒つきの選択肢)、「プロセス」(入力、出力、矢印)の構文を理解する必要が ありますが、それ以上のことはありません。しかも、C#や Java のような従来のプログラミング言語 よりは間違いなく読みやすくなります。
関数型ドメインモデリング ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう p.97
まとめ
既に総評っぽいことを書いたあとなのでここに書くことがなかった！
考え方の良いインプットになる本だったし、少なくとも部分部分のエッセンスについては普段の開発にも取り入れていけそうだなと思った。というか今現在実際にやっている。
そして、少し上に書いたばかりだけど改めて言及しておくと、日本語で読めるのは便利ですね！
