Fuctinonal and Reactive Domain Modeling社内読書会をはじめました

こんにちは。株式会社セプテーニ・オリジナルの高嶋です。
社内で有志を集め、 Fuctinonal and Reactive Domain Modeling の読書会を始めたのでその紹介と、第一章を読み終わった時点での感想です。

目的

これはボク個人のこの本に対する期待になります。
弊社ではDDDをScalaで実践してきましたが、多くのプロダクトはOOP的であり効果的に関数型を活かせてないのではないかと疑問を感じていました。この本では、DDDと関数型プログラミングを融合させるテクニックとそれをScalaで実践する方法が学べることを期待しています。

開催方法

今回は以下のような進め方をとりました。

毎週木曜日18:30から開催する
全員が自分で読んでくることを前提とする
読む量は毎回終了時に決める

以上のような形で進めています。
英書なので全員読んでくるはなかなかハードですが、平均的には15pほどなのでGoogle翻訳を頼りにしても読み切れる量だと思います。
また当日には先に全部読んでしまった人や、英語が得意な人が意味がわからなかった部分に関してサポートしてくれるので安心です。

ここまでの内容

一章の内容は大まかには以下のようなものでした。順におさらいしていきます。

DDDの簡単な紹介
関数型プログラミングのメリット
「失敗」との向き合い方
イベントソーシングの紹介

DDDの簡単な紹介

弊社では中途入社でも新卒でも必ずエリック・エヴァンスのドメイン駆動設計を読みます。
なので言葉の紹介まわりはサラッと読み流しました。
話題になったポイントとしては「サービスがエンティティやバリューオブジェクトと異なるのは粒度である」という点でした。
粒度というのはここでは「エンティティやバリューオブジェクト同士の関わりを表現する方法」という意味であったと考えています。
あまり粒度という視点では考えたことがなかったのでなるほどなと感じました。

この本ではエンティティやバリューオブジェクトが振る舞いを持つことを推奨していないようです。
これはなかなか衝撃でした。
弊社のプロダクトコードでは基本的に振る舞いは出来る限りエンティティとバリューオブジェクトにもたせているため、全く考え方が異なっています。
それらが持っていた振る舞いを持つべき場所はサービスであるようです。
サービスに移したことで純粋な関数として表現出来ることが期待でき、テストや関数の合成の面でのメリットが得られるようです。

ドメインサービスが副作用を保つ場合があるが、できるだけ局所化し純粋な部分とは切り離すことが推奨されています。
そうしないとテスト時にやけにモックが必要になったり、ドメインロジックが理解しづらくなるよと警告されています。
モック地獄で喘いでいるプロダクトもありなかなか耳が痛い章でした。

関数型プログラミングのメリット

ここはよく言われているようなメリットが挙げられていたかと思います。

小さい関数を組み合わせて大きな関数を作れる
参照透過性をもたせることで検証が簡単になる

「失敗」との向き合い方

ここではReactiveを構成するための4つの要素(Resilience、Elasticity、Message driven、Responsive)の、Resilisenceの説明の中でちゃんと失敗を前提にした設計をしようということが書かれていました。
失敗のハンドリングがモジュール(この本では境界づけられたコンテキストのこと？)を越えないよう、そのモジュール内で完結することを推奨しています。
逆にモジュール内で処理しない場合、各箇所でボイラープレート的なエラーハンドリングコードが出現したり、失敗の処理方法をプラガブルにできなくなるといったデメリットが挙げられています。

イベントソーシングの紹介

ここまでの内容とは少し変わってイベントソーシングの紹介です。
従来の設計ではRDBMSに記録されるのはある時点でのスナップショットであり、過去のある時点でどうだったかの検証は大変でしたよね。
ログを記録しておいて検証可能にしておいたとしてもそのログを探し出すのも手間だしなんとかならないでしょうか。
ここでは開始時点の状態と、それに対して起きたすべてのイベントを記録していき、利用の際には開始時点の状態にイベントをすべて適用すればよいと紹介されていました。
そうすることにより、ある時点での状態もその時点までのイベントを再生することで得られるようになります。