『関数型ドメインモデリング』の感想など
『関数型ドメインモデリング ドメインっ駆動設計とF#でソフトウェアの複雑さに立ち向かおう』を読みました。
概要
前提知識について
「はじめに」の記載によると、本書は「ドメインモデリングの手段として関数型プログラミングが実際に優れており、明確かつ簡単な設計を生み出せる、と示すこと」を目的としたものであり、「本書を読むためには、ドメイン駆動設計や関数型プログラミングの予備知識は必要ありません」とされています。
実際には、F#に関する知識は不要であるものの、関数型プログラミングに関する基礎知識がないと、読み進めるのに苦労するかもしれません。「int -> int -> int」のような関数の型の記法、カリー化、部分適用、関数の合成といったところは分かっていて、なんとなくモナドの雰囲気を知っていれば、ストレスなく読めると思います。
本書の構成
本書の構成は以下のとおりです。
第1部 ドメインの理解
第1章 ドメイン駆動設計の紹介
第2章 ドメインの理解
第3章 関数型アーキテクチャ
第2部 ドメインのモデリング
第4章 型の理解
第5章 型によるドメインモデリング
第6章 ドメインの完全性と整合性
第7章 パイプラインによるワークフローのモデリング
第3部 モデルの実装
第8章 関数の理解
第9章 実装：パイプラインの合成
第10章 実装：エラーの扱い
第11章 シリアライズ
第12章 永続化
第13章 設計を進化させ、きれいに保つ
本書の内容
第1部 ドメインの理解
第1部は導入であり、ドメイン駆動設計とは何であるのか、なぜドメイン駆動設計を行うのか、どうやってドメイン駆動設計を進めるのか、といったトピックが語られます。イベントストーミングという手法を用いたドメインの探索、すなわち対象の業務領域に存在するモノやコト、イベントの抽出や、ビジネスワークフローの理解の進め方についての説明がされています。受注システムというケーススタディを用いて、具体例で説明されているのでとてもわかりやすいです。
イベントをトリガーとし、コマンドによって開始されるワークフロー（一連の業務手続き）、結果として生み出される別のイベント、というように「入力と出力を持つパイプライン」としてビジネスプロセスを捉えると、関数型プログラミングの仕組みと非常にマッチするというのが、本書の肝です。第3章では関数型アーキテクチャが紹介され、第2部以降では具体的な設計と実装の方法が提示されます。
第2部 ドメインのモデリング
第2部のテーマは、解決空間においてドメインをどうモデリングし、表現するかです。主役は型です。とりわけ代数データ型の持つ強力な表現力を用いて、ドメインの完全性と整合性が担保されたリッチなモデルをコードで表現することができます。また、ビジネスワークフローも、個々の処理ステップを担う関数の型を定義し、それらを合成することで表現できます。
ビジネスプロセスを表す「入力と出力を持つパイプライン」を、（まだ実装を持たない）型だけで表現することが、本書におけるドメインモデリングすなわち設計です。
第3部 モデルの実装
第3部では、型で表現したドメインモデルを実装していきます。ここから関数型プログラミングが本格的に使われるため、冒頭に第8章「関数の理解」が配置されています。ただし、15ページ程度の分量なので、おさらい程度と考えた方がよいです。
関数型プログラミングによるパイプラインアーキテクチャの構築方法を、実践的かつわかりやすく、エレガントに示してくれることが本書の価値だと考えます。特に10章「実装：エラーの扱い」では、成功と失敗の二系統がある関数を合成により連鎖していく方法（2トラックモデル）が、プラレールのような線路のイメージを用いて非常にわかりやすく説明されており、目から鱗が落ちました。
誰に薦めるか
ドメイン駆動設計に取り組んでいる人、これから取り組もうと考えている人、とにかく設計が好きな人にお薦めできる良書だと思います。
本書は、「そもそもなんでドメイン駆動設計でやるんだっけ？」という根本に立ち返らせてくれるものです。ソフトウェアが取り扱う業務は複雑であり、業務の専門家ではない開発者が簡単に理解できるものではありません。そのため、ドメインストーミングなどのワークセッションを通じて、ドメイン専門家との対話を重ねながら共通の語彙（ユビキタス言語と呼ばれるもの）を構築し、それを用いてモデリングを行います。
そうやって作られたドメインモデルは、これから作るものが「正しい」ものであることの検証を容易にします。業務の仕組みや構造、概念に合致している（あるいは乖離が少ない）モデルを、ステークホルダー間で「共有されたメンタルモデル」として利用できるからです。（本書では、型で表現されたドメインモデルは、ビジネスの人間が読んでも理解することが可能、とされています。実際にビジネスの人が読むかどうかはさておき）。
ただし、ドメインモデルはあくまで解決空間におけるモデルであることは理解しておく必要があります。解決手段（ソリューション）の構築のために必要となるモデルだということです。境界づけられたコンテキスト（Bounded context）を定義する必要があるのも、そのためです。本書の第1章にある記述が参考になるので、引用しておきます。
なぜ境界づけられているのでしょうか？ 現実の世界では、ドメインの境界は曖昧ですが、ソフトウェアの世界では、別々のサブシステム間の結合を減らし、それらが独立して進化できるようにしたいのです。そのためには、サブシステム間に明示的なAPIを設けたり、共有コードのような依存関係を避けたりするなどの、標準的なソフトウェアの手法を用います。これは悲しいことに、ドメインモデルが現実世界ほどは豊かにならないことを意味しますが、複雑さを減らしてメンテナンスを容易にすることと引き換えなら許容範囲です。
解決空間においてソースコードを実装する際は、当然ながらプログラミング言語やフレームワークが持つ表現力が制約となります。我々は、その制約下において、もっとも「ましな」ドメインモデルを構築する必要があります。
オブジェクト指向と関数型のどちらが優れているという話ではなく、それぞれが有している表現力に違いがあるので、向き不向きがあるのは当然です。（例えばデシジョンテーブルで表現される業務ルールは、オブジェクト指向でも関数型でもなく、ルールエンジンが提供するDSLやスプレッドシートの方が、明瞭に表現できるでしょう）。
そういう意味では、対象のドメインを表すのに最も適した表現力を有する言語を採用するということは、マイクロサービス化の一つの動機たり得るのかなと思いました。
少し長くなってしまいましたが、とにかく設計本が大好きという方に対しては、間違いなく一読の価値がある本だと思います！（どこかで感想戦やりたい）
また、2024年7月20日に発売予定の、増田亨さんが翻訳した以下の本も、良書の匂いがプンプンしているので、読み比べてみるのも面白そうですね！
いいなと思ったら応援しよう！
