FLINTERS Engineer's Blog

FLINTERSのエンジニアが綴る技術ブログ

ドメイン駆動設計(DDD)との格闘 - 広義のドメイン・狭義のドメインの理解

こんにちは、株式会社FLINTERSで企画職 (Product Owner、ProductManager、ProjectManager、雑用係などの総称)として働く加藤と申します。 私は、主に、インターネット広告代理店などデジタルマーケティングを実践されている企業へ、Yahoo!GoogleFacebookなどの広告媒体が提供するAPIなどを活用した、業務用のアプリケーションを開発提供するお仕事に携わっております。

引き続きFLINTERSでは、ブログ投稿強化月間です。

企画職としてのドメイン駆動設計(DDD)への参加する時の心得について書いておりますが、第3回となる今回は、ドメイン駆動設計(DDD)における、【ドメイン】という言葉の謎に迫っていきたいと思います。

前回までの振り返り

第1回では、企画職として実践できるようになっておきたい、ドメイン駆動設計(DDD)の手法として4つをあげ、第2回で、ユビキタス言語について述べてきました。

【企画職として実践したいDDD手法】

  1. ユビキタス言語の発見・作成・普及
  2. 広義のドメイン・狭義のドメインの発見・作成
  3. コンテキスト境界の発見・作成
  4. コンテキスト境界同士の関係性の発見・作成

今回は、ドメイン駆動設計(DDD)という名前の通り、鍵となる考え方の【ドメイン】という言葉について理解を掘り下げていきたいと思います。 ※あくまで私個人の考え方なので、「おい!全然間違っているぞ」という部分を見つけた方は優しく教えて下さい

ドメインという言葉が混乱の元

DDD本を読むと、ドメインという言葉がありとあらゆるところに現れます。

ドメインエキスパート、コアドメインサブドメイン、汎用サブドメイン、支援サブドメインドメインモデル、ドメインオブジェクトなどなど。 そして、ドメインという言葉は通常ビジネスサイドでは事業領域といった意味で使われており、『当社の今期の注力ドメインはDX支援です』と言ったような使われ方もします。

DDD本といえば、エリック・エヴァンス本が最初に推奨されると思いますが、この本は私の読解力の限りでは、ドメインについての説明がないまま、当たり前のようにほにゃららドメインという言葉が記述されていて、ほにゃららドメインの詳細の記述はわかったけど、ドメインって何のことだかピンとこないなあと、私は何度読んでも感じておりました。 エリック・エヴァンスのドメイン駆動設計

実践ドメイン駆動設計(Vaughn Vernon ヴァーン・バーノン)本が理解を助けてくれた

このなんだかドメインって何のことだかわからないなあという状態が暫く続いていたのですが、同僚からのアドバイスで開眼(!)しました。

あるプロジェクトで既存のシステムをリビルドすることがあり、開発初期から、ドメイン駆動設計(DDD)に携わることができる機会がありました。ハノイと東京の両拠点の混合開発チームによるプロジェクトで、まずは東京側のエンジニアと私で、ドメイン分析・設計をすることになったのですが、そのエンジニアも今回が初のDDDプロジェクトであり、私と二人で何から手を付けてよいのか途方に暮れておりました。

その時同僚がアドバイスしてくれたのが、実践ドメイン駆動設計 この本の2章にある、実世界におけるドメインサブドメインという項でした。

ドメインは、問題空間と解決空間を持っている。問題空間は、解釈すべきビジネス戦略上の課題を浮き彫りにするもので、もう一方の解決空間は、ソフトウェアをどのように実装してその課題を解決するかに注目するものだ。

問題空間はドメインの一部であり、新しいコアドメインを生み出すための開発を要するところである。... 問題空間とは、コアドメインと、そこから使う必要のあるサブドメインをあわせたものとなる。

解決空間は境界づけられたコンテキストのことで、特定のソフトウェアモデルの集合となる。

あれ、、、当時はこの文章読んでビビビッと電流が走ったように理解が進んだのですけど、ピンとこない。。。もうちょっと言葉を噛み砕いてみましょう。

まず、一旦、何の装飾もついていない「ドメイン」という言葉を、『業務領域』といった言葉に置換します。(事業領域だとちょっと広すぎる。)たとえば、インターネット広告代理店の事業を、提案・営業業務領域、広告運用業務領域、クリエーティブ制作業務領域、請求業務領域という4つの業務領域に分けるとします。そしてあなたの開発チームは、広告運用業務領域を管轄する部署の仕事をするとします。

この、広告運用業務領域というのが、今回の開発における「ドメイン」です。ただ、これだとさすがにざっくりしすぎていますね。開発によって何を良くしたいのかわかりませんね。なのでもうちょっと設定を足しましょう。『広告運用業務領域におけるレポート業務を効率化してほしい。』これが、あなたの開発チームの今回のミッションです。

コアドメインサブドメインの一種である

さてもう少し今回のドメイン、『広告運用業務領域』について分析を進めましょう。

広告運用業務領域の仕事を分析してみると、営業マンが受注した内容に従って新たな広告アカウント(YahooやGoogleの運用型広告アカウント)を開設する業務、クリエーティブ担当が制作した制作物を広告アカウントに入稿する業務、受注した条件に従って運用型広告アカウントの入札条件やターゲティング条件などを操作して広告効果をコントロールする業務、広告アカウント(YahooやGoogle)のシステムから広告結果を日々取得する業務、広告主向けに広告出稿結果レポートを作成する業務。このような5つの業務に分解したとします。

これが、今回の『広告運用業務領域』ドメインを構成する、5つのサブドメインです。

ここで、注意点。ドメイン駆動設計(DDD)本を読むと、ドメインをコアドメインサブドメインに分けて、コアドメインに集中しようみたいな記述がありますが、コアドメインサブドメインの種類の1つです。

ドメインを構成する、5つのサブドメインがあったとしたら、そのサブドメインのうちどれをコアドメインとして、どれを、サポートサブドメインや、汎用サブドメインとするのかは、ドメイン分析の腕の見せ所の一つですが、どれも、『広告運用業務領域』ドメインを構成する、サブドメインの話です。ドメイン分析のあとに行う、システム設計における、ドメインオブジェクトなどの話は、すべてサブドメインの中の話です。 つまり広義のドメインが、『広告運用業務領域』ドメインで、狭義のドメインが、『レポート作成業務』などのサブドメインです。

さて、色々ごちゃごちゃしてきたので、一旦、ここまでを図にしてみます。

f:id:waruta_k:20210331224040j:plain

問題空間を特定する

さて、ここであらためて問題空間について考えましょう。

問題空間はドメインの一部であり、新しいコアドメインを生み出すための開発を要するところである。... 問題空間とは、コアドメインと、そこから使う必要のあるサブドメインをあわせたものとなる。

あなたの開発チームに課せられたミッションは、『広告運用業務領域におけるレポート業務を効率化してほしい。』でした。 ただ、どうやらヒアリングをすすめると、レポート業務に業務工数が多い理由は、レポート作成フォーマットに原因があるのではなさそうです。広告結果の取得がたびたび失敗しているために作り直しが発生している、また業務開始時間からレポート作成作業が出来ないことが多い。また、広告制作物の画像をレポートに添付するためには、毎回制作者担当にメールで個別で送って貰う必要があるなどなど、複数の要因が絡み合って発生しているようです。むしろレポート制作自体は、上手にテンプレート化されていて、決まった形式のCSVと画像ファイルがあれば、ある程度自動的に作成ができているようでした。

そこで、あなたは、今回のプロジェクトの問題空間として、広告結果取得業務をコアドメインとして、サブドメインとして広告レポート業務、そして、制作物広告入稿業務、アカウント開設業務、広告効果向上業務の一部にも関係するので、それもサブドメインとして設定することにしました。

これを図にしてみるとこんな黄色の範囲のイメージです。

f:id:waruta_k:20210331230124j:plain
問題空間の特定

そうなんです。問題空間の特定は、分析業務だけではなく、ここから「意思決定」が入っているんですよ。なので企画者の腕の見せ所ですね。

実際には、分析やヒアリングがすらすら進むわけではなく、ドメイン『広告運用業務領域』の理解や5つサブドメインの発見のために、調査・ヒアリング・プロトタイプ開発などをしながら、ドメイン分析を進めていくの有用なわけですがそれはまた別の機会にでも。

解決空間を決める

さて、問題空間が特定できたとします。そうしたら、いよいよ開発物によって何をどう解決していくか、解決空間を考えるステップに移ります。 この解決空間を考えるにあたっては、『境界づけられたコンテキスト』を策定する必要があります。

次回のブログでは、コンテキスト境界の発見・作成について、記載していこうと思います。