こんにちは、 @kz_morita です。 今回は、 『関数型ドメインモデリング ドメイン駆動設計とF# でソフトウェアの複雑さに立ち向かおう』 という本を読んだので感想を書きます。 書籍について 『関数型ドメインモデリング ドメイン駆動設計とF# でソフトウェアの複雑さに立ち向かおう』 という本で、アスキードワンゴから出版されています。 2024 年 6 月 28 日に出版されているので割と新しめな本です。 以下のような目次の内容になっています。 推薦のことば 日本語版へ寄せて 訳者まえがき はじめに 第1部　ドメインの理解 第1章 ドメイン駆動設計の紹介 第2章 ドメインの理解 第3章 関数型アーキテクチャ 第2部　ドメインのモデリング 第4章 型の理解 第5章 型によるドメインモデリング 第6章 ドメインの完全性と整合性 第7章 パイプラインによるワークフローのモデリング 第3部　モデルの実装 第8章 関数の理解 第9章 実装：パイプラインの合成 第10章 実装：エラーの扱い 第11章 シリアライズ 第12章 永続化 第13章 設計を進化させ、きれいに保つ 著者紹介 訳者紹介 感想など X (旧 Twitter) でこの書籍が発売されたことをしり、関数型でドメインモデリングするという非常に興味深い内容だったので購入して読んでみました。 大きく分けて 3 部構成になっています。 1 部では、ドメインを理解することについて書かれていて、DDD でいうところの戦略的設計について書かれています。 2 部では、モデリングについてで型を使ってモデリングしていく方法について書かれています。 3 部では、実際に関数型でどのように実装するかという点を F# を使ってかなり具体的に書かれています。

前から読みたかったDDD本を、読み始めたので雑にメモしていく。 ドメインとは、そのシステムが解決したい問題の領域のこと。 DDDにおいてのモデルとは、以下のようなもの 設計と相互に形成し合う チームメンバが使用する言語の基盤 蒸留された知識 設計と相互に形成し合う これはDDDがモデル駆動開発で進められることを意味している。 設計時にモデルを書きそこからコードを書き始める。 また逆に、コードを書き始めて気づいたことなどをモデル側にも反映させることでモデルとコードを一緒に成長させていく。 チームメンバが使用する言語の基礎 これは後ほど出てくるユビキタス言語について。 チームメンバ同士がコミュニケーションする際には、モデルや実際にコード上で表現されている言葉を用いる（逆にコミュニケーションに用いられる言葉をコードに落とし込む） 蒸留された知識 モデルはドメインの知識をそのまま反映したものであるべき。 モデルと実装が紐付いていれば、コードから得た知見をモデルに反映できる。 そうして、どんどん知識は噛み砕かれてよりドメインを明確に表すものに蒸留されていく。 これらの設計を進めていくためには、ドメインの知識を噛み砕く必要がある 第1章 知識を噛み砕く ドメインエキスパートの頭の中にあったり、過去のシステムなどからドメインに関する知識を得ることが重要で、繰り返し継続的にドメインに関する知識を学習する必要がある。 得た知識の中から重要な概念を抽出し、それをそのままコードに落とし込む。 オブジェクト指向でよく言われる、名詞を抽出するという手法の他に、 ビジネスルールなども概念として抽出する。 ビジネスルールなどはよくif文の中などに現れる。 例えばATMでお金を引き出せる時間かどうかのロジックについて考えると、 以下のように書かれることがある。（適当な疑似コード） Time now = Time::Now(); Time am9 = Time(9,0,0); Time pm10 = Time(22,0,0): if (am9 < time && time < pm10) { // 引き落とし処理 } このようにしてしまうと、処理の中に重要な業務ルール（引き落とし可能時間） が隠れてしまう。 そこでPolicyクラスなどを作成すると良いとされている。 if (businessHourPolicy.isAllowed(Time::Now())) { // 引き落とし処理 } ただしこのような手の込んだ設計はどこにでも適用することは推奨されていない。 ドメインの中でも特に重要となる知識に対して行うことが重要。 このようにして書かれたコードはドメインエキスパート（非エンジニア）にもコードを見せることができ、プログラマの手助けがあれば理解することができる（はず）。 また、コードを書いたことによる気づきなどをモデルにフィードバックさせ、知識を深めていく。 深いモデル アプリケーションが解決しようとしている問題の核心を表すうまいモデルのこと。 深いモデルを見つけるために、開発を続け、ドメインの知識について継続的に学習・嚙み砕きを行うことが重要とされる。 雑なまとめ DDDはモデル駆動開発 モデルをコミュニケーションに活用する より深いモデルのためにドメイン知識の嚙み砕きを継続的に行う