Domain modelling made functional Chapter1, Chapter 2を読む

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# (English Edition)という本を読んでいる。自分で理解で端的に書くならば、ドメイン駆動設計をFunctional Programmingに落とし込んでいくためのどう考えるか・どうするか?を述べている本だと思う。今、社内で輪読会が行われていて、これがとても面白いのでちょっとばかり自分の理解のため、忘れたときのために書き残しておく。

全体的にどんな本かは、以下のQiitaに素晴らしいまとめがあるのでこちらを読めば良いと思う。自分も参照しています。

qiita.com

Chapter 1 Introduction Domain-Driven Design

第1章はDDDの大事な大前提をギュギュッとまとめつつ*1Event Stormingを用いてドメインイベントを洗い出し、ワークフローを浮かび上がらせていこうとしている。

面白いなと思ったのは、エリック・エヴァンスのドメイン駆動設計だとインタビューなどを通してエンティティや値オブジェクトにビジネスロジックを集めようとするが、ここではイベントとそのイベントによって生成されたコマンド、コマンドを入力としてワークフローが駆動され、またイベントが発生し次のコマンドに……という動的な流れそのものに着目しているところ。このあたり自分の納得度が高く、この考え方はいいなと思った。

Event Stormingによってイベントをさらに拡大させ、大きなドメインサブドメインへ分割する話や境界付けられたコンテキストの発見へと至るのは感動がある。ただどうやって境界付けられたコンテキストを見つけ出すかは、

This is an art, not science

となっていて、この部分機械的に解決はできないのね。難しい。

あと、ユビキタス言語を生きたドキュメントとしてちゃんと残しておくのはいいことだ、と書かれておりモデルと実装を一致させるDDDにおいても、生きたドキュメントは必要だろうと自分は考えていたので、ポイント高い。

Chapter 2 Understanding Domain

第2章からは、ドメインエキスパートへのインタビューでいろんな質問を通して、一つの境界付けられたコンテキストを深掘りしていく。最初に読んでて思ったのは、当たり前ではあるのだが、ドメイン駆動設計の大枠に則って話を具体的に進めているので、Functionalでなくとも参考になる部分が多いなということ。データベース、つまり技術的な詳細に引っ張られないようにする、技術的な言葉ではなく通じる言葉で質問するなど、オブジェクト指向でのDDDでも大事なことだ。

深掘りを経て、新しいユビキタス言語が追加されたり、Event Stormingでは見つからなかった新たな境界付けられたコンテキストを見つけたりした結果が、36ページのワークフローになる。この図を見たとき自分は集約がこれに置き換わったのかなと思ったが、実際にEvent Stormingではワークショップを通して集約などを見つける手法だと後から知ったので、自分の感想はいいところをついていたようだ。

というところでここまで。次はChapter3を読んでいきたい。

koboにもあるんだ……

*1:開発者の仕事とは何かやメンタルモデルの共有の大事さなど