「DDD-Community-Jp」主催が語るドメイン駆動設計

松岡幸一郎氏:では、「ドメイン駆動設計 モデリング/実装入門 勉強会」を始めたいと思います。

自己紹介です。松岡と申します。「DDD-Community-Jp」というオンラインのDiscordコミュニティの主催や、DDDのブログを書いたりしています『WEB+DB PRESS』の去年の10月号では、DDDの特集を書かせていただきました。今回の「技術書典」(技術書典8)では、単著で1冊、同人誌を出しました。

今日とくに、僕の顔はここでしか出ないので、「こんな顔です」となんとなくイメージしていただけると。よろしくお願いします。

技術書典8に向けて、『ドメイン駆動設計 モデリング/実装ガイド』という本を書いたのですが、残念ながらコロナの影響でなくなってしまい、せっかくなので代わりに何かオンラインで発表する機会を設けようかなということで、今回開催しました。

本の内容は、DDDの概要を紹介するものです。ちょうど、本書の1章・2章あたりが「DDDとは?」という話をして実際にドメインモデリングしてコードに落とすような内容になっているので、そこをご紹介し、もし興味があったらほかのところも「こんなのあるよ」という感じで紹介していければと思っています。

今回のイベントのスポンサー

「DDD-Community-Jp」では、オンライン輪読会とかをけっこうやっているんですが、こういうふうに一方的に発表するようなやり方は初めてでして……。オフラインの勉強会をどのぐらい(オンラインで)できるかなというのを考えてみました。

前に立って発表するところがYouTube Liveによる配信になっていて、Twitterのハッシュタグのツイートはふだんどおり、いつもの勉強会のような感覚でやっていければと思っています。

YouTube Archiveは残す予定です。Twitterのほうも、チャットとどちらがいいのかは、試し試しというか、僕もどういう使い分けになるのか興味があると思っています。普通のイベントの感覚でTwitterのタグも投稿していただければと思います。お好きなほうで投稿してください。

ということで、不慣れな点も多々ありますが、お付き合いお願いいたします。

(今回はイベント参加者の)人の人数が増えてきたので、スポンサーさんについてもらいました。少し紹介したいと思います。株式会社Loglassさんです。ゴールドスポンサーとして協賛してもらいました。事前にもらった紹介文をそのまま読み上げたいと思います。

「弊社は予算の収集・策定をGitHubのように差分管理、数値の変更のイベント管理、権限管理できるクラウドシステム、いわゆるBtoB SaaSです。創業1年経ちませんが、SaaSで海外VCからも資金調達し、上場企業10社程度の導入もすでに決まっています。創業メンバーとしてDDDも活用しつつ、お客様から本当に愛されるプロダクトを作り上げませんか? ぜひ一度オンラインでもオフラインでもお話しましょう。詳しくはWantedlyまで」とのことです。

私がDDDの勉強会などをやらせてもらっている、ちょっとお手伝いさせてもらっているところです。先ほどnoteで、すごく興味深いというかおもしろい記事が上がっていました。「BtoB SaaSスタートアップだからこそ、DDDを」という、お客さんと向き合うようなSaaSだからこそDDDがなぜ合っているかということが書かれた記事です。勉強会の紹介記事になっていておもしろかったので、ぜひ一度見てもらえればと思います。

(コメントで「サーバサイドKotlinいいね!」)Kotlin? サーバサイドでKotlin、すごくいいですね。Javaで書いていてKotlinいいなって。こちらのきっかけで勉強しているんですけど、Kotlinすごくいいですよね。

「#ddd_mcじゃないのかな?」とコメントいただいているんですけど、ちょっとmcはわかりづらかったので「#ddd_guide」のほうにタグを変えたので、ハッシュタグはこちらでお願いします。

今コメントをいただいた坂本さんという人が、CTOの坂本さんです。勉強会の紹介記事だったんですが、なぜDDDかというのがおもしろかったので見てもらえるとありがたいです。

DDDはそんなに難しくない

では、今日話す内容について紹介します。実は話す内容は、この間の「OOC」(Object-Oriented Conference)の内容とけっこう重なるところがあります。後半のライブコーディングの部分が新しいところなので、もしこの間の内容を見ていただいた方は、後半だけ注目して見ていただいてもよいかもしれません。

概要として、「DDDとは?」。「そもそもDDDって何なんだっけ?」というのを混乱している方が多いと思うので、「DDDとは?」というところと「モデルとは何なのか?」。それから「よいモデル・悪いモデルとはどういうものか?」について、最初にお話ししたいと思います。

そのあと、モデリングからコードに落とすところを実際にやってみようと思います。実際やってみて「なかなかよくなったな」というのを、コードを見ながら感じていただけるとよいなと思っています。そのあとは、「じゃあ、実際にどうやって導入していくの?」というところへの簡単な紹介をしていきます。

ちょうどこの「DDDの概要とモデリングから実装まで」というところが、(本書の)1章と2章の内容になっているので、そのあと、ほかの章ではどんなことを紹介しているかを軽く紹介させてください。

サンプルコードと資料は、先行して配信しています。サンプルコードはこちら。資料も何かトラブルがあったときのために、こちらのリンクを見ておいてもらうといいかと思います。YouTube Liveの詳細のところにも書いているので、そちらから見てもらえれば、コメントが流れても見れるようになっています。

今日のゴール。これを見た方にどうなってもらいたいかですね。まずはDDDの開発や概要の流れを理解してもらいたいと思っています。それから、「DDDはそんなに難しくないな」と思ってもらえると。「DDDについて、もっといろいろ知りたいな」と思ってもらえるといいなと。

ソフトウェアは何のために作る?

それでは、「DDDとは?」という説明から始めていきます。DDDとは何でしょうか? 最近いろいろと本が出てきて、わかりやすい資料も増えてきましたが、1年前とかは、いい本がぜんぜんなかったので、「DDDってそもそも何だっけ?」ということすらよくわからないような時代がけっこう続いたのではないかと思っています。

今コメントで「難しいイメージしかないです」というふうに書かれましたが、そうだと思うんですよね。そこを押さえていこうと思います。抽象的なところから押さえると、(DDDとは)ソフトウェア開発手法の1つであるということです。ソフトウェア開発をいかに効果的に効率的にやるかという手法の1つだと言えます。

では、そもそもソフトウェアというのは何のために作るのでしょうか? それは、「ソフトウェアを適用する対象の何らかの問題を解決するため」と言えるでしょう。

例えばタスク管理。このあとも出てきますが、タスク管理のアプリケーションを導入することで、今までは付箋などで管理していたものが、それだと管理が漏れてしまったり自動で通知できなかったりとか、そうした効率的ではない問題が、より効率的になる、というようなことですかね。

ドメインとドメイン駆動開発

こうしたソフトウェアで問題解決をしようとする対象の領域のことを「ドメイン」と呼びます。この「ドメイン」という言葉自体が非常によくわからない、馴染みのない言葉だと思うんですが、このようなものをドメインと呼ぶと思ってください。

DDDはそもそも「ドメイン駆動設計」の略です。そのドメインというものを起点に設計していきましょうということです。

「DDDってこういうものだよ」というふうに書かれている文章です。「DDD Referenceより」と書いていますが、「DomainLanguage.com」というサイトからです。ここの「ABOUT US」のところに、あの青い本(エリック・エヴァンスの『ドメイン駆動設計』)の著者であるエリック・エヴァンスの名前もあるので、ほぼ公式情報だろうということで……。

ここの「DDD RESOURCES」の中に、『Domain-Driven Design Reference』という本があります。コメントでも「初見殺しですよね」と書かれている、この本(「エリック・エヴァンスのドメイン駆動設計」)の非常にエッセンス的なものを抽出してある、すごく薄いPDFです。迷ったら定義とかは、ここを参考にするようにしています。

Domain-Driven Design Reference: Definitions and Pattern Summaries

DDDの目的はコード品質のさらに先にある

ここにはDDDについて、「多くのプロジェクトはモデリングを行っても最終的な大きな利益を得られないまま終わります。DDDは、モデリングから劇的な利益を得られたプロジェクトから、成功するパターンを抽出します」と書かれています。

つまりDDDは、ソフトウェアの価値を高めるソフトウェア開発技法なんですが、そのときのアプローチとして、「ドメインモデリングを使うよ」と書かれているわけです。

ここで「あれ?」と思われた方もいるのではないでしょうか? アーキテクチャとかコードの話がぜんぜん出てこない。いわゆるDDDって、だいたい8割方、ソフトウェアのコードが汚くて苦しんでいるところに希望の光として手を出すようなパターンが多いかなと思っているんですが、実はここで、最初の目的としては「モデリングでソフトウェアの価値を高める」と言われていて、そこの話が出てこないんです。

コード品質を上げることを目的としてDDDの導入を検討されることが多いのですが、実の目的は、コード品質のさらに先にあることになります。

では、コード品質は関係ないのかというとそんなことはなくて、コード品質も高めつつモデリングの効果も出すというふうになっています。そこのつながりも今日お話ししたいと思います。