この記事はCrowdWorks Advent Calendar 2017の4日目の記事です。

はじめに

今年CrowdWorksにエンジニアとして新卒入社した@kinakoboです。CrowdWorksでは10月から新たな試みとしてドメイン駆動設計（DDD）を実践しています。
DDDを実践するに至った経緯は、サービスの規模拡大に伴いアプリが肥大化し、技術的負債が増えてきたことで、機能追加をスピーディーに進めづらくなってきたからです。
今回実装しようとしている機能を今まで通りRuby on Railsを利用して実装することは可能ですが、変更に強い柔軟なサービスにするためにもDDD+Scalaで実装し始めています。

DDD未経験の状態から2ヶ月実践してみて、まだ道半ばですが感じたことを書きます。同じような課題感を持っている方の参考になれば幸いです。

エヴァンス本に挫折したら･･･

DDDと言えば、入門するためにあの分厚いエリック・エヴァンスのドメイン駆動設計や実践ドメイン駆動設計を読む必要があるというイメージでしたが、自分は書いてあることのイメージが掴めず、すぐに挫折してしまいました。
思えば、あやふやな設計の知識しか持っていなかったので、まずは設計やDDDの全体像を把握しようということで、以下の書籍と記事を読みました。

現場で役立つシステム設計の原則
- 設計の考え方や方法を知る
- 書いてあることを実践すると、オブジェクト指向が身につく
DDD超入門(後編) - Domain-Driven Designの適用Step
- DDDの基本構成要素を知る

これらを読んでからだと、前述の本に書いてあることのイメージがつきやすくなり、読みやすくなったと感じました。

ドメインモデルの設計は何度も変更・改善する

初期のモデル設計では、決まっていない仕様や見えていない業務知識が多く、完璧なドメインモデルを設計することはできないです。
業務知識が深まったり、今より適切な設計を見つけるたびにどんどんモデルを変えていく必要があるので、変更しやすいコードにしておくと積極的に変更することができて良いです。

変更しやすくするためには、静的型付け言語を使ってオブジェクト指向で書くことである程度担保されると思いました。
これは自分が今まで動的型付け言語であるRubyを書いていたので、今回静的型付け言語であるScalaで書いてみて、型があると単純なエラーの混入を防げるので、楽に安全に変更が行なえると思ったからです。
オブジェクト指向で書く理由は、そのままですがオブジェクト同士の依存関係を管理しないと変更が困難になってしまうからです。

ドメインモデルの全体像を見渡す

ドメインモデルの設計が大きくなってくると、その時はよかれと思ってドメインモデルを追加していても、後々全体像を見ていると「あれ、ここ変だね」と気づくことが何度かありました。
全体像を見渡すためにも、ドメインモデルを図に起こしていると把握しやすいです。

都合によりモザイクをかけていますが、このようにホワイトボードシートに付箋とペンで雑に書いていました。これを見て修正に繋がった例としては、Entity同士の関連を作らず値をマッピングすれば済む箇所があった、ValueオブジェクトにできるものをEntityにしてしまっていた等がありました。
設計が進むに連れオブジェクトの数が増えてホワイトボードシートで管理しづらくなったため、今はdraw.ioにデジタル化しています。

開発者だけで進めない

DDDは本来、ドメインエキスパートと呼ばれる業務知識のエキスパートと開発者で行いますが、今回は業務仕様が決まっていない0からのスタートで、ドメインエキスパートは存在しませんでした。そのため、開発者が業務知識のエキスパートになっていく必要がありました。
しかし、開発者だけでDDDを進めていると、どうしてもユビキタス言語や業務フローが開発者の知識に寄っていき、利用者側での目線が薄れていました。

そのことに気づいたのは、デザイナーと連携して画面仕様を考えたときでした。デザイナーの気づきにより、開発者の間で使っていたユビキタス言語を利用者にとってもわかりやすい言葉に言い換えたり、画面遷移図を元に業務フローに改善の余地があることに気づけました。

ドメインエキスパート不在でDDDを行う場合は、デザイナーに限らず利用者目線で考える事に長けた人を巻き込んでおくべきだと思いました。

迷ったら先人の知恵を借りる

当たり前ですが、設計に迷ったらDDD経験者に聞いてみたり、類似サービスを参考にしてみるとヒントが得られたりします。
例えば、商品を購入できるサービスを作るときは amazon を参考にしてみると、注文時に注文明細が発行され、商品が出荷される直前に購入明細が発行されていて、それぞれどんな値を持っているのかといったことがわかります。

最後に

個人的にDDDはとっつきにくいイメージでしたが、やってみると意外とそんなことはなく、やればやるほど良い設計に近づいていくので、やりがいがあり楽しいです。
数年後に新たに加わった人が手を加えることになっても、仕様を把握しやすく変更しやすいサービスになっていることを目指し、今後もDDDを追求していきたいと思います。
まだまだ自分のDDDに対する理解は浅いものなので、また理解が深まったら記事にして発信したいと思います。