ドメインモデリングワークショップを開催しました

image_name

こんにちは、ギフティでエンジニアをしている @memetics10 です。普段は Gift Experience dev unit というチームでギフトの発行基盤に関わる開発をしています。

先日、有志による社内勉強会の一環としてドメインモデリングワークショップを開催しましたので、今回はそのレポートを共有します。

開催に至った経緯と目的

ギフティの多くのプロダクトには、Ruby on Rails が採用されています。

ソフトウェアを作る様々な方法がある中で、Rails を選ぶ大きな理由の一つとして、フレームワーク自体に強力な設計方針が備わっていることが挙げられます。 MVC や RESTful を中心に据えた強い規約があることで、それほど重要でない設計の意思決定に時間を奪われることなく、機能開発に集中することができます。設計の意思決定をある程度 Rails におまかせする利点は、時間的なコストを削減できることだけでなく、最低限の品質を担保できることにもあります。ファットモデルのようにフレームワークの仕組みだけで解決できない問題はあるものの、適切なテーブル設計の上で規約に従いさえすれば、経験が浅いエンジニアでもそれほど悪い作りになりづらい点も Rails がフレームワークとして優れている理由の一つです。

一方で、Rails のようなフレームワークがエンジニアにとって唯一のツールになってしまうのは問題だと考えています。ここで私が問題視しているのは、エンジニアのスキルやキャリアについてではありません。また、技術選定の幅が狭りがちなことも大きな問題ではありますが、それも最大の問題ではないと考えています。最大の問題は、アーキテクチャスタイルのメガネを通してドメインを眺めてしまうことです。

MVC や RESTful のような Rails を支えるコンセプトは、アーキテクチャスタイル、すなわち物事を整理する方法の一つです。アーキテクチャスタイルはエンジニアのために技術的な問題解決の手段を提供してくれますが、ソフトウェアを使うユーザーにとっては無関係なことがほとんどです。ドメインを理解し、ユーザーの問題解決のために工夫を凝らすことは、アーキテクチャスタイルの選択と本来的には無関係なはずです。

特定のアーキテクチャスタイルに縛られた思考が、本来あるべき問題解決を妨げてしまうのは、ユーザーデメリットに直結します。例えば、リソースの CRUD という枠組みの中で問題解決を探ると、イベントのような重要なドメインの概念を見落としてしまうかもしれません。ソフトウェアは使う人のために作られるべきであって、作る人の都合が優先されるのはなるべく避けたいところです。

かくいう私も、Rails からエンジニアとしてのキャリアをスタートした一人であり、初めはフレームワークが用意してくれている枠組みの中でしか問題をとらえられていない時期がありました。しかしここ 3 年ほど、Rails から離れて開発してきた経験から、Rails しか知らなかった頃と比べて見える世界が変わってきました。

これを個人の経験に留めておくのはもったいないという思いから、「Rails のアンラーニング」を一つのテーマとして、ドメインモデリングワークショップを開催することにしました。

ワークショップの内容

ワークショップは社内のイベントスペースにて、丸一日使って開催しました。コンテンツは二部構成で組んでおり、前半は数名ごとのチームに分かれてドメインモデリングを行い、後半はハンズオン形式でモデルを実装をしました。

eventstorming

ドメインモデリングは、電子クーポンのドメインに基づき、そこに架空の問題を設定して取り組みました。モデリングにも様々な方法がありますが、今回はイベントストーミングを利用しました。イベントストーミングについてあまり知らない方は、イベントストーミングの勘所の記事でも紹介しているので読んでみてください。

イベントストーミングは参加者全員にとって初体験だったので、最初は一定の難易度があったものの、すぐに有益な議論が自発的に交わされるようになり、大変盛り上がっていました。イベントストーミングのコラボレーティブな性質が発揮されていたと感じます。

余談ですが、イベントストーミングにおいて集約を発見するパートは他の部分と比べて難易度が高いです。最初から集約を見つけようとするのではなく、先にコマンドが失敗する理由を洗い出し、最後に集約に名前をつけることで進めやすくなります。

普段 Rails で開発をしていると、ドメインモデル=データモデル(≒テーブル設計)と捉えてしまうケースがしばしば見られます。データモデリングは非常に重要ではあるものの、それだけでは不足しています。データモデルは、ドメインモデルの一部分だからです。ドメインモデリングをするならば、部分だけでなく全体をよく見る必要があります。今回のイベントストーミングのワークを通して、ドメインモデルとは何なのか、ドメインモデリングとはどういった営みなのかを再認識する機会になったと思います。

後半は、ドメインモデリングによって得られたモデルに基づいて、参加者に実際に手を動かしてもらいながら実装を行いました。ゼロからアプリケーションを作ってもらうには時間が足りないので、主催側で事前に雛形アプリケーションを用意しておき、参加者には足りていない部分を埋めてもらうような形式を取りました。雛形アプリケーションのアーキテクチャスタイルには GraphQL や CQRS を採用しており、これは参加者に普段と異なる開発を経験してもらうことや、ドメインモデルをそのまま実装に落とし込む経験をしてもらうことが狙いです。なお実際に使用した雛形アプリケーションを以下のリポジトリで公開しています。

Go 実装(https://github.com/kousuke1201abe/cqrs-example-go)

Ruby 実装(https://github.com/kousuke1201abe/cqrs-example-ruby)

慣れ親しんだ MVC とは大きく異なるアーキテクチャスタイルだったため、多くの参加者が苦労していたようでしたが、最終的にはほとんどの参加者が意図どおり動く機能を実装できていました。 Rails とは全く異なるアーキテクチャスタイルで実装することで、普段どれほど Rails の恩恵を受けているのか、逆に Rails に足りていない点はどこなのか、普段使っている技術を相対化して理解するきっかけになったと思います。

ワークショップの成果

当初目的としていた「Rails のアンラーニング」は達成できたと感じています。特にイベントストーミングはかなり好感触で、普段 Rails に慣れているメンバーにとっては、テーブル設計の話が出てこないのが新鮮な体験だったそうです。実務に活かせそうだと感じてくれたメンバーもおり、特定の技術的な枠組みに縛られずにドメインモデリングを行うきっかけを作れたと思います。

後半の実装パートに関しても、Rails の考え方との違いを学んでもらっただけでなく、イベントストーミングで得たモデルをそのままコードに落とし込む感覚を掴んでもらえたようでした。 Rails のような MVC と全く異なるアーキテクチャスタイルをすぐに実務で活用するのは難しそうでしたが、少なくともアーキテクチャスタイルの視野を広げる第一歩にはなったかと思います。