KitchHike Tech Blog

KitchHike Product, Design and Engineering Teams

ドメインモデリングをやってみよう。社内勉強会で「ドメイン駆動設計」について発表しました

f:id:taogawa:20210926053730p:plain

こんにちは。エンジニアの小川です。

キッチハイクでは定期的に社内勉強会を開催しています。

先日は「ドメイン駆動設計のはなし」というタイトルで私が発表させていただきました。

speakerdeck.com

本記事では発表スライドの補足として発表の概要と個人的な考えについて記したいと思います。

発表について

ドメイン駆動設計(以下DDD)とは、エリック・エヴァンス「ドメイン駆動設計」で提唱されている手法に端を発する、ドメイン(システムの対象領域)知識のソフトウェアの反映に焦点をあてた設計手法です。

本発表ではこのDDDについて以下のようにお話ししました。

  • ドメイン駆動設計の概要
  • Ruby / Railsにおけるドメイン駆動設計
  • それを踏まえてDDDをキッチハイクとしてどのように進められるか

Railsにおけるドメイン駆動設計

Railsでのドメイン駆動設計において、よく取り沙汰されるのがRailsのデフォルトORMであるActive Recordと、その基となっているActive Recordパターンです。

Active Recordパターンはデータベースのテーブルの構造とエンティティの構造が同一であることを前提としています。したがって、永続化層の構造と、ドメイン層の構造が密結合する形となります。

Railsはその思想として、こうした単純化を意図的にやっています。DHHがインタビューで言っているように、Railsは「20%のソリューションで問題の80%を解決」することを目指しているからです。テーブルとエンティティの構造を同一のものとして扱うことで、マッピングは大幅にシンプルになります。そして大体の場合において、このアプローチでカバーできます。

一方でDDDのアーキテクチャのアプローチとしては、ドメイン層とインフラストラクチャ層(ここでは永続化層)は疎結合であることが望ましいです。DDDの書籍において紹介されるRepositoryは、この考えを体現したアーキテクチャの技法のひとつです。

このアプローチの違いはDDDのアーキテクチャをRailsに適用するにあたってコンフリクトする点のひとつとなります。そして、現時点において、これを解決する有力な選択肢は数が少ないように思えます。

ではどうするか

とはいえ、それはあくまで「アーキテクチャ」のみの問題であって、DDDを進めていくにあたってはもっと他の部分に目を向けるべき、というのが、本発表で最も強く主張したかった点です。

DDDにおいてはこれまでアーキテクチャ的な部分がフォーカスされがちな傾向がありました。かくいう私自身もDDDはアーキテクチャから入ったクチです。しかしながら、DDDのアーキテクチャ部分ばかりにフォーカスされると、RailsにおけるDDDの適用にはあまり良い評価にならないように思います。一番避けたいのは「RailsだからDDDができない」といった短絡につながってしまうことです。

DDDにおいて提唱されるアーキテクチャは、DDD全体においては一部分にしかすぎません。よりよい設計、開発をDDDで進めたいと思うなら、もっとできることがあるはずです。

そんなわけで、本発表ではその中のひとつとして「ドメインモデリング」を挙げました。

ドメインモデリングについては、DDDの書籍においてもどのようにモデリングすべきかというのは書かれてはいません。ただ、一般的なモデリングの知見はドメインモデリングにおいても非常に有用なものとなるように思っています。

UMLを使った概念モデリングや、DB設計におけるデータモデリングの知見はすでにたくさんの蓄積がありますし、書籍などを通じて学ぶこともしやすいのではないでしょうか。

ひとつ気に留めておきたい点としては、DDDはドメインエキスパートとの対話や、実装から得られたフィードバックを継続的に反映していく開発プロセスだという事です。したがって、モデリングも一度きりではなく、継続的にアップデートされていくものになっていきます。

そうした点も踏まえたドメインモデリングのプロセスは、松岡幸一郎さんの書かれた「ドメイン駆動設計 モデリング/実装ガイド」が非常に参考になります。

booth.pm

最後に、個人的にはDDDはそのプロセスにおいて、開発者が必然的にビジネスドメインに向き合い、越境することになるのがとても良い点だと感じています。

ともすれば、開発者はビジネスドメインの要件を所与のものとして受け止めがちです。けれど、DDDにおいてはドメインモデルを理解し、よりよいものとしていくために、開発者はドメインエキスパートとの対話を通じて、自ずとビジネスドメインに踏み込んでいくことになります。こうしたプロセスはよりよいプロダクトを作ることに繋がるのみならず、開発者にとっても新たな視点をもたらしてくれるものではないでしょうか。

We're Hiring!

キッチハイクでは、ドメイン駆動設計に興味があるエンジニアを募集しています!

www.wantedly.com

www.wantedly.com

www.wantedly.com