Septeni Engineer's Blog

セプテーニ・オリジナルのエンジニアが綴る技術ブログ

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

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

目的

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

開催方法

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

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

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

ここまでの内容

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

DDDの簡単な紹介

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

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

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

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

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

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

「失敗」との向き合い方

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

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

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

疑問

ここまでで我々の中で解決できていない疑問を上げておきます。
今後読み進めていく上での課題となっています。

  • 業務では実際のところ、特定の業務を組み合わせることはないので関数の合成は必要ないのではないか?
  • Actorを用いない設計の場合、ビジネスロジックと例外処理コードの分離はどのように実現すればよいのか?

感想

1人だとなかなかとっつきづらい洋書ではありますが、何人かで集まると進めやすいですね。
社内の人間だけであればプロダクトコードと本の内容を照らし合わせながら会話出来るのも大きなメリットです。
まだまだ導入なので比較的サクサクと読んできましたが、今後モナドなど出てきた際のスピードが危ぶまれます。