DDDは古典である
DDDとは
DDD。日本語でいうとドメイン駆動設計である。
Wikipediaには以下のように記されている。
ソフトウェアの設計手法であり、「複雑なドメインの設計は、モデルベースで行うべき」であり、また「大半のソフトウェアプロジェクトでは、システムを実装するための特定の技術ではなく、ドメインそのものとドメインのロジックに焦点を置くべき」であるとする。DDDで設計するのはビジネスや社会における諸問題を「解決する」ためである。
ビジネスの「諸問題」問題
ビジネスや社会における「諸問題」と述べたが、ビジネスは問題定義から始まるといわれる。問題を発見し定義する。それが「諸問題」となる。そしてその解決の枠組みを組み合わせる。その組み合わせがビジネスのモデルであると言える。
しかし、近年は「問題が希少」で「解決能力が過剰」になっているという。
諸問題とはいっても希少化しているのであれば新たに見つけることになる。
問題定義からの再出発
現在DXが話題のひとつとなっている。DXは以下のような定義になるようである。
DXとは、一言でいうと「企業がデータやデジタル技術を活用し、組織やビジネスモデルを変革し続け、価値提供の方法を抜本的に変えること」ビジネスモデルを変革し価値提供の方法を抜本的に変える、つまりこれは
- 新たに問題を定義する
- 新たに解決の枠組みを作る
ということである。つまりデジタル技術で「問題が希少」「解決能力が過剰」を乗り越えてようということである。
DXを行おうとする企業や既存IT企業、ITスタートアップをはじめデジタル技術で問題を解決しようとする組織（や個人）は、デジタル技術を振るうまえに問題定義からはじめることになる。
デジタル技術を前提とした解決の枠組み
問題定義をしたら当然次は解決の枠組み、解決手法が課題となる。それはDDDでいうところのドメイン、つまり業務領域として定義されるといえる。
デジタル技術を利用した問題解決は当然デジタル技術の存在を前提としたドメインとなるのではないだろうか。そしてそれはDXやIT系スタートアップ（ベンチャーといった方がいいのかもしれない）においては新たな問題・新たな方法であるのでそこにはドメインは存在しないのである。
閑話休題。「DX時代」以前においてもドメインは本業の人でも理解していないことがままあったらしい。マニュアルがない、用語が正式に定義されてない、IT化によりブラックボックスになっている、といった理由からであるそうだ。
話を戻すと、現代でも別の要因によりドメインが不明な状況が発生しているのである。そしてそのドメインはどうやらデジタル技術を含み、非IT企業にとってそのドメインを構築するのは単独では困難であると考えられる。アメリカなどでは企業がIT技術者を雇い内製化しているらしい。またスタートアップの多方面への進出は目覚ましい。
デジタル技術によるドメイン
スタートアップに所属している技術者の方は、技術者もビジネスのことを考えて欲しいと経営層から思われていることを感じているのではないだろうか。スタートアップでなくても経営者的視点を求められるのも同様のことなのかもしれない。前項で述べたようにデジタル技術を前提とした場合、ドメインの構築のために技術者が参加する必要があるからだと考えられる。さらにいえば技術が問題を解決するならば技術者が問題定義から参加することも重要であると言える。外部の力を借りるのであればIT企業が問題定義から参加することになる。
問題定義・ドメイン構築にIT企業やその技術者が参画するということは、自身がドメインエキスパートの一人になるということである。それも、はじめは存在しないドメインの、である。
現代におけるDDD
DDDは「解決」の手法であると述べた。ドメインエキスパートと連携してユビキタス言語を定義しドメインモデルを構築していく。
しかしこれまで述べてきたようにIT企業や技術者が技術が組み込まれたドメインを新たに構築していく時代に、非IT企業の「既に存在するドメインのドメインエキスパート」と連携するだけで対応できるだろうか。それは少なくともDXにおいては否であるといえる。ITスタートアップにおいては既存のドメインエキスパートは存在すらしない。
先にドメインを構築しておいてDDDで解決する、という意見もあると思うがIT企業や技術者が構築（さらには問題定義）時点で組み込まれ、デジタル技術を利用したドメインを構築する前提であり非IT企業がドメインを構築しておくのは不可能である。当然IT系スタートアップは独自にドメインを構築するのであるから、解決手法では歯が立たない。もし先に構築できるとしても、次にDDDを利用する、というのは二度手間である。はじめからモデルを含めて新たなドメインを構築する方が良いのである。
リーンスタートアップはドメインを構築しつつ開発を行う方法であると考えられる。さらにはピボットという問題定義を再び行う行為も存在する。
このように私はDDDでは対応できない時代となり、問題定義から解決まで一気通貫した手法が求められている時代ではないかと考えているのである。
ではDDDはもう役に立たないのだろうか。私はそうは思わない。ドメイン駆動という考え方は現在の状況でも十分役に立つはずである。エンティティやバリューオブジェクト、アグリゲーションなどの実装面での活躍も期待できる。つまりタイトルのように古典として学び、現代に通じる部分を取り出すことが重要だと言える。
おまけ
おまけとしていくつか考えていることを書いておく。
今回は技術者に関しての考察だが、デザイナも当然関係してくる。以前デザインにも抽象化が存在すると教えられたのだが、それは「蓋」ではなく「あけられるもの」というようにより上位の概念にさかのぼっていくことらしい。ビジネスにおける問題定義も同様の抽象化を行うと良い、というか、それが本質なのかもしれない。「新しい手法」にはデザイナも組み込まれて、開発者と一緒に作業することになるのではないか。
DXにおけるユビキタス言語はデジタル技術やその概念を含むものとなると考えられる。非IT企業のドメインエキスパートには理解が難しい用語が出てくることが考えられる。非IT企業とIT企業が連携する場合、ユビキタス言語の定義にはそのような問題があり、どのように解決しているのだろうか。
DDDの実装面の特徴のひとつにレイヤードアーキテクチャがあげられるが、Clean Architectureと結びついて多くのレイヤーに分けられることがある。DDDはドメインに注目した手法であり機能的凝集が重要であると私は考えており、多くのレイヤーに分けることは機能的凝集を毀損することになりかねない。現代においてRuby on Railsは密結合により機能的凝集を高める方向に向かったと私は考えている。批判はあるが成功も収めているのは間違いない。結合度と機能的凝集のバランスをとるためにレイヤーの構成は十分な検討が必要だと考えている。
ドメインサービスという名前は実装においては曖昧すぎる。なぜそのような名前になったかを考えたのだが、実装内容は若干抽象的な概念となるのでドメインエキスパートが理解できるユビキタス言語として表せなかった面があるのではないか。上記のユビキタス言語の定義問題にもかかわるが、具体的に命名することができないだろうか。ユースケースとして定義する場合もあるらしいので、命名については工夫が必要だろう。
なぜこのような文章を書いたのか。DDDを知った時に旧来のSIer的だと思ったからである。それ以上にはなれない。ITの時代は作れないと考えたのである。何年もかかってやっとこの文章を書くことができた。時代が教えてくれたと思う。
おまけが長い…
