みなさんこんにちは、ネクストビート編集部です。

今年3月に開催された ScalaMatsuri (https://2018.scalamatsuri.org/) の後日イベント「NextMatsuri」を5月12日にネクストビートの恵比寿本社で開催いたしました。当日、スマートニュースの瀬良様と、ChatWorkの加藤様にご来社頂き、当社CTOの衣笠とトークセッションを開催させていただいたのですが、その内容が非常に濃かったので、何回かに分けて配信させて頂いております！

過去記事：

【エンジニアイベントvol.6】3社はなぜScalaの導入に至ったのか～Nextbeat (衣笠) x SmartNews(瀬良) x ChatWork(かとじゅん)トークセッション①～

https://www.wantedly.com/companies/nextbeat2/post_articles/120681

本日は「DDDの導入タイミングに対する考え方」に関して配信させていただきます！

Q- DDDの導入タイミングは企業の規模、考え方、価値観によって違うと思いますが、ChatWorkとネクストビートのDDD対する考え方を教えてください。

※以下、敬称略

加藤：

僕がChatWork社にいるから「 ChatWork は会社として いっせいにDDD をやろう」 で、みんなが僕の指示に従っているとイメージされる方が多いかもしれませんが、実はそんなこと全くなくメンバー各位で自発的にやってますよ（笑）プロジェクトで DDD を実践したいエンジニアがいて、その方が現場でレビュー・設計を含めチームメンバーと一緒になって進めています。ChatWork ではチームの中での合意形成を大事にしており、ドメインモデルに関してもリードするエンジニアが中心になって現実路線で進めています。

僕が入社したタイミングでは、Scala化プロジェクト(Falconプロジェクト)としてシステム刷新プロジェクトがありました。ScalaMatsuriでお話したとおり、紆余曲折を経て、メッセージ基盤刷新プロジェクトとして再出発して最終的に成果を残せました(詳しくはこちらを参照してください)。当時は、DAUの増加と相まってメッセージ数もかなり増えてきて、これまでの考え方ではサービスレベルを維持できない状況でした。そのような危機的な状況を回避するためにも、DDDの考え方から貢献できることはないかと考えました。結果的に、Akka, HBase, KafkaをベースとしたCQRS+Event Sourcingシステムを採用することで、目下のリスク回避とさらなる非機能要求に応える基盤を作ることができました。

また、このFalconプロジェクトでは、社内によりよいプラクティスを生み出し(社内的にはFalcon wayと呼んでいる)、横展開も始まっています。さきほども触れましたが、チームメンバーで合意形成ができて、一緒に DDD を実践してロールモデルとなるような実績が残せるようになりました。そうやって文化が根付くことで、プラクティスとして安定して実践していけると思っています。ソースコードとして DDD 風になっているよりも、まずエンジニア間で ドメインを中心に考える文化をつくっていくことの方が大事だと思いました。

衣笠：

そうですね、弊社が重要視しているのはドメインモデルそのものではなく、それ以外の集約だとか、それをとりまくところをどこまで実装過程で落とすか、というところです。DDD の考え方を全てコードに落とすこともできるとは思いますが、それをやってしまうと開発効率が落ちてしまうことになるので、省くところは省かないといけないと思っています。

DDD ＝ 開発、DDD = プログラムの作り方、ではなくて、むしろ開発以外の合意形成をやるツールとしての考え方の方が大きいかなと思っています。

ネクストビートに DDD を取り入れようって思ったときに、加藤さんを呼んで最初にやってもらったのはワークショップです。 DDD の考え方を用いて、時間軸に従って設計をコンテキストごとに区切って、どれがコアドメインなのかを文献を含め定義していきました。共通言語を作ることが、重要ですね。

スクラム（※1）の考えの中でも共通言語を真っ先に作るべきと言われており、根幹にあるので、手段は違っても似ているところは結構同じなのかと思いました。

加藤：

軌道に載ってきていますね。ウチもFalcon以後、まだ残っているPHPコードの、ドメインモデルを再定義しようというプロジェクトも立ち上がっていて、僕がコードレビュー・デザインレビューとかをやっているのですが、そういった草の根の改善活動が自然と起こっています。

スタートアップでは議論する時間もないぐらい、速度重視で立ち上がらなければならないので、DDDを採用するかどうかについては入社した当時に異論もありましたが、Falcon wayの浸透と共に成果が出て、メンバーの認識も変わってきました。ドメインモデルがあることで設計の意図も明確になり、日々の議論も効率的になります。

ChatWorkと同様に二次成長期に入る企業でもDDDの採用事例が多くありましたが、こういった成功体験を詰んだ企業も少なくないと思います。一方、スタートアップではスピード重視で設計重視でDDDを採用しにくいという話は聞いていましたが、最近はスタートアップでも採用する会社が増えています。経験者が増えたというのもあると思います。

司会：

ありがとうございます。DDDの導入を検討されていてもっと詳しく質問したい方もいるかと思います。質問ある方いらっしゃいますか？

Q- DDD を導入するときに文化が大事であるとのことですが、文化を作るためにどういうことをされたのかということと、実際に DDD に初めて取り組みエンジニアをどう育成しているのか教えてください。

加藤：

考え方や価値観を実践で共有するようにしています。特にコードで見える形で。エンジニアはコードからものを考えるのがやりやすく、コードがないところで説明するのは難しいので、何かしら実装例をふまえながらコードを見せながら説明しています。

「モデリングする際に実装コードのことを考えすぎだ」という人もいますが、DDDでは分析と設計で単一のモデルを使うため、表裏一体だと思います。モデルをイメージできなければ、コードや画面から考えてもいいし、ときには離れてみてもよいですね。そういう体験からどのような違いがあるか、わかってからでないとドメインモデルは語れないですし、お互いの考え方を共有することが大事ですね。

少し話しは逸れますが、DDD では「責務駆動設計」という書籍から影響を多く受けていますが、「アレグザンダーのやかん」の責務は何か？という話が出てきます。ただの「水の容器」としてみるか、「水の沸騰を誰かに通知するオブジェクト」とみるか、どのような視点でユースケースを考えるかで変わってきます。前者はモデルの静的な視点で、後者は動的な視点が含まれており、問題や課題を自律的に解決する性質が含まれています。レバレッジの効く設計をするには後者の視点は欠かせません。”やかん”をどういうオブジェクトとしてみるのか、なぜそういう役割をもとめるのか、という Why のところを考えるのがすごく難しいです。

話を戻しますが、よりよいモデルを追求するには、こういったモデルに対する考え方を共有する文化をつくることが必要なんだと思います。

衣笠：

そうですね、弊社では、昔も今も文化的には意外と変わっていなくて、共通項があるかと思います。

昔も、どういうふうにサービスを作ろうかとなったときに、モデルをしっかり作って片付けられるわけでもなく、１番手っ取り早く相手の設計者にそれを伝える方法が昔はデータベースのER図だったと思います。

「データベースのER図がちょっとずつドメインに置き変わっていって、ER図では表現できないテーブルとテーブルの関係性を表現しやすく取り入れたものですよ」って古い人に説明していくと、「あ、そうなのだね」と理解してもらいやすいかもしれないですね。

DDD って三文字の言葉で強そうでプロレス技みたいに聞こえるのですけど（笑）

DDD という単語から懸念される状況を、緩和させていくのも重要かもしれないですね。

加藤：

設計といえば、データ指向でER図からという人が、オブジェクトを中心に考えていくにはどうしたらよいか皆さん悩んでいるので、マイグレーションする方法があるとよいですね。

Eric本を読んでもそのあたりはよくわからないので、ICONIXなどの古典を読むとよいと思っています。さらに、それを現代風にかみ砕いて説明するガイドがないとなかなか難しいので、それを最近Scalaコミュニティーで話させていただいています。

衣笠：コンサルタントですね（笑）

加藤：

宣伝になっちゃうのですけど、Discordっていうチャットサービスで、DDD Community-JP という DDD のコミュニティーが立ち上がりました。そこで気軽に聞いてもらえれば、僕以外の方からアドバイスをもらえると思います（笑）。Scala だけじゃなくてGoやRuby で DDD やろうとしている人もいますし、そういうところで質問してもいいかとも思います。

瀬良：

昔は Scala も敷居が高いと言われていて、始めようと思ったけどよくわからないという人が多かったように感じます。DDD もそのような状況から、自然に参考になる事例が多くなってきたかと思います。

加藤：

昔の難しいと今の難しいでは状況が変わっています。昔はサンプルとか記事がない中、色々調べたり考えたりした上で記事を書いていました。今は僕の記事を読んでくれる人が多いんですけど、今読み直してそれにフィードバックくれる人がいて、「昔書いたときはよくわかってなかったのですが、今考えると違う視点がありましたね」って盛り上がれたりするのがありがたいです。難しいっていう言葉だけでは片づけられない、数年かけてやってきた積み上げは大きいのではないかと思います。

※1：アジャイルソフトウェア開発手法

続きは【ChatWorkとネクストビートのDDDに対する考え方トークセッション②-2】をご覧ください！

興味をお持ちいただけた方は、Wantedlyで掲載中の募集職種から、ご連絡ください。Wantedly以外の経路より優先して選考のご案内を差し上げます。選考ではなく、まずは話を聞いてみたいという方も、現時点でご関心がある職種の募集ページからご連絡お願いいたします。