関数型ドメインモデリング - 第1章の感想
はじめに
普段、月に5-10冊程度は本を読むのですが、inputばかりであまり身についていない感覚もあるので、これからはブログで読んだ本の感想をアウトプットしていこうと思います。
まずは、現在読んでいる関数型ドメインモデリング ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおうについて、各章ごとに感想を記載していきます。
第1章の感想
第1章では、ドメイン駆動設計（DDD）の概要が紹介されていました。この章では、特に以下のポイントが重要だと感じました。
用語の紹介
この章では、以下のような重要な用語が登場しました。
これらの用語については詳細な解説はありませんでしたが、業務システムの開発における業務要件定義と似た分析作業を行う際に使用されるものであると感じました。
業務要件定義との類似点
業務要件定義では、業務要件や業務フローを定義し、現場ユーザーとの認識の齟齬を防ぐために用語集を整備します。これに対して、DDDにおいては各用語がそれに相当する内容を持っていると理解しました。
特に、DDDが生まれた背景には、伝統的な業務要件定義では解決できない課題があったためではないかと考えています。
DDDと伝統的な業務要件定義との違い
本章のまとめとして、以下の4つのポイントが挙げられています。
- データよりもイベントやプロセスに焦点を当てる
- ドメインをより小さなサブドメインに分割する
- 各サブドメインのモデルを解決空間に作成する
- プロジェクトに関わるすべての人が共有できる「ユビキタス言語」を開発する
特に、「データよりもイベントやプロセスに焦点を当てる」という点が、伝統的な業務要件定義と異なると感じました。
業務システムの設計では、データフローやデータそのものを厳密に分析し、データモデルを構築することが多いです。
しかし、DDDではそれよりもイベントやプロセスに焦点を当てることを推奨しています。
本章の冒頭では、従来型の開発（おそらくウォーターフォール型開発）では、ドメインエキスパートからの情報が十分に伝わらないため、開発チームとドメインエキスパートが直接的に協力する必要があると述べられています。
そのためにドメインモデルなどの共有が重要であるとしています。
一方で、従来型の開発でも実際の開発者がドメインエキスパートと深い対話を行いながら業務システムを開発するケースは存在しており、自身もそのように開発を行ってきました。
そのため、従来型の設計スタイル vs DDD という単純なものではないな、というか、きちんとDDDが必要とされる背景を理解する必要があると感じました。
さいごに
本書を読み始めて、改めて「DDDがなぜ必要とされるようになったのか」という点についてわかってるようでわかってなかった、ということに気づきました。
今後、本書を通じて、なぜDDDが必要なのか、という点をより深く理解していきたいと思います。
