ドメイン駆動設計の背景
株式会社株区スタイルの後藤秀典です。
この番組では、エンジニアリングチームで起きている問題について
技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、ドメイン駆動設計との向き合い方、です。
ドメイン駆動設計、DDDですね。
聞いていらっしゃる多くの皆さんが知っているアプローチ、手法だと思うんですけれども
私自身、結構これにハマっていたというか、取り組んだ時期がありまして
私なりの考え方というものを持っておりますので
今日はそれについて、一コマ分使ってお話したいと思います。
エンジニアリングマネージャーの問題集
今日は、ドメイン駆動設計について話していきたいと思います。
このポッドキャストは、エンジニアリングマネージャーというところをテーマにしてはいるんですけれども
エンジニアリングマネージャーであれば一定、技術のところに立ち入って
何らかの意思決定だったりだとか、チームを導いていくとか
そういうことも必要だったりするので
こういった設計に関する考え方、価値観とか
そういうところもきちんと持っておく必要があるのかなというところで
今日はこれに振り切った話をしようと思います。
ドメイン駆動設計、聞いてくださっている方
多くの方はご存知の設計手法なのかなと思っております。
書籍としては、エリック・エヴァンさんの書いたドメイン駆動設計という本が
日本語での翻訳も出ておりますが
英語版で出版されたのは2003年だったかな、ぐらいですね。
日本語版が10年遅れぐらいで出版されたというタイムラインです。
もともとのエリック・エヴァンさんの英語版の本が書かれた時点でも
確か相当エヴァンさんが何年も何年も現場で
いろんなことを取り組んできた集大成として
書かれている本だと僕は理解しているので
多分この本が出来上がるそうですね、どうなんでしょう
10年ぐらい前からエヴァンさんは何となくこのような考え方を元に
現場で仕事をしてきたといったような感じかなと思っています。
なのでこのドメイン駆動設計と名付けられた本が出たのは2003年なんですけれども
それよりももっと前から実際の考え方みたいなものは
エヴァンさんに限らずいろんなエンジニアが現場で
試行錯誤しながらやってきた中にはあったのではないかなと思っています。
ドメイン駆動設計と非常に近い位置で扱われる考え方が
オブジェクト思考とかもあったりするんですけれども
この辺りでいうと1980年よりももっと前とかいうところで登場してきていて
現場で使われてきている考え方だったりするというところがあるので
ドメイン駆動設計もそれと結構近いタイムラインのところで
実際この特にエヴァンさんが現場でいろいろ試行錯誤してきた中で
最終的に名付けられた概念だったりするわけですよね。
そういった背景があります。
ドメイン駆動設計とは何かっていうのを実は説明するのは
非常に難しいかなと思っておりまして
ドメイン駆動設計の意義
原著が2003年、日本でも2013年に出て
それから10年以上経ってるんですが
なかなかこのドメイン駆動設計とはこうであるみたいに
答えが出た感じは未だにTwitterだとかいろんなところ見ていても
あまりしてなくてですね
いろんな考え方として見られる設計手法なのかなと思ったりしています。
とはいえ私自身は特に日本語版が出たあたりですね
自分自身の活動の一環として
このドメイン駆動設計にのめり込んだといいますか
一度しっかりこのドメイン駆動設計というものの考え方につかりきって
根底にある考え方からしっかり理解して
自分のものにしようと思って
数年間かなり取り組んでいた時期がありました。
その当時というのは僕は
メインで一緒に活動していたパートナーと一緒に
例えばそのドメイン駆動設計を教えるような
トレーニングコースを作ったりだとか
あとはプログラマー向けのカンファレンスで
ドメイン駆動設計に関わる講演をしたりだとか
ということもしていましたし
それを当時の私の理解なので浅かったかもしれませんが
とはいえ本をさらっと読んで
理解しただけの知識でやってたというわけではなく
例えばたまたまその当時運良く
年でいうと10歳ぐらい上の方々ですかね
エンジニアとしての先輩の方々と
出会うコミュニティに参加しておりまして
そのコミュニティで行った議論だとかが
私自身のドメイン駆動設計だったり
そもそもシステムやソフトウェアの設計というか
モデルとはみたいなところが
どういったものであるべきかみたいなところに対する
理解をすごく深めるのに役立ったというのがあって
本当に結構時間を使って
このドメイン駆動設計というものと
僕は向き合ってきた中でそのような活動をしていました
なので一定
ドメイン駆動設計のいいところは
当然ある程度理解したつもりでおりますし
一方で書籍としてというか手法としてというか
あまり良くないというか足りていないというか
そういうところもあるなというのは結構
自分自身で語れるぐらいにはなっておるかなと思っております
そんな私が今
ドメイン駆動設計というものが何なのかというのは
まずシンプルに説明するとしたら
まず一番大事なコンセプトは何かといったときに
ビジネスと向き合ってソフトウェアを作れという
この一文に尽きるかなと思っています
ビジネスと向き合ってソフトウェアを作るの中身がどうあるのかというのは
色々なアプローチというかやり方があるわけで
対象としているビジネスによっても変わってくるところがあるし
ビジネスの内容によって使える
使った道具というのが変わる場合もあって
その道具によって作る作り方というのが
変わる場合もあり得るとは思います
そういった対象とするものによって変わるよねということが
エリック・エヴァンさんの本にももともと書いてあるんですよ
なのでドメイン駆動設計というのはもともと
そういった幅のある実装方法に関しては
色々な適したやり方を自分で考えてねみたいな部分がある本だったわけですよ
と思っています
ですが繰り返しになりますが一番重要なメッセージは
ビジネスと向き合ってソフトウェアを作れということかなと思います
ドメイン駆動設計の課題
ただこのビジネスと向き合ってソフトウェアを作るというのが
どういうことなのかってなかなか分からないんですよね
普通
特に今現代ですと色々なソフトウェアの開発ツールも便利なものが揃っていて
サーバーサイドのコードでもフロントエンドのコードでも
書こうと思えばどっかのサンプルサイトみたいなところを見ながら作ることが
割と比較的やりやすくなっている時代かなと思っています
なのでソフトウェアを作ること自体はものすごく始めやすいんですけれども
ビジネスと向き合うって言われた時に多分多くの人が
それってどういうことなのかっていうのが分からないんですよね
それに一定の答えを出しているのが
このドメイン駆動設計というアプローチの懐の広さみたいなところがあると思うんですが
まだ答えにたどり着いていない人からすると
これは僕も最初そうだったんですけれども
がこのドメイン駆動設計というものに触れると
本に書いてある作り方のパターンみたいなものを使って
ソフトウェアを作ることがドメイン駆動設計だっていうふうに
勘違いしちゃうのかなというふうに思っています
これは僕もそうでした
なのでそこはドメイン駆動設計というものを学ぼうとすると
大抵通る道なのかなとは思いますが
それ自体がすごく悪いとかいうわけではなく
例えばエリック・エバンスさんの本に書いてある作り方のパターンが
今でも役に立つ対象の業務っていうのはあると思っていますし
それでうまくビジネスを表現できる
引いてはビジネスと向き合った形になるっていう場合も
ゼロではないというか普通にあると思います
実装の仕方みたいなところは例が書いてあるんだが
本当はその例だけがドメイン駆動設計のやり方というわけではなくて
他にもいろんなやり方があるものでしたというところです
この辺はなかなかドメイン駆動設計の分厚いエリック・エバンスさんの本に
一番最初の方に産業とかでまとめて書いてあればいいんですけれども
そういう書き方にもなっておらずですね
ドメイン駆動設計とは何ですみたいに
答えがどこにも載ってないんですよね
いろんな人が解釈の幅が広い考え方だとするので
いろんな言い方で分かりやすく説明してくださったりもしているので
逆にちょっと分かりづらくなってしまっている状況ができているかなと思っておりますが
僕の言葉で言うと これ大事なので何度も繰り返すんですが
ビジネスに向き合ってソフトウェアを作るというのがドメイン駆動設計です
これ 僕自身は相当これに人生の時間を費やしてきたので
僕が今の僕になる過程でとても大事なものだった
僕の人生で欠かすことのできないピースだったなとは思ってはいるんですけれども
どうですかね これからもしドメイン駆動設計を学ぼうとされている方にとっては
ドメイン駆動設計の価値の不明確さ
対して僕が言えることとしては
そこまでのめりすぎなくてもいいのかなって思っているところがあったりします
ちょっと後ほどこの辺りにまたお話ししようかなと思っています
言ってドメイン駆動設計というものをやってきたんですけれども
じゃあ今の時点で僕がこのドメイン駆動設計というものに対して
どう考えてるのかっていうところをお話ししたいと思います
で これどうなんですかね 皆さんやってらっしゃる方の意見も
いろいろ聞いてみたいなと思うところではあるんですが
僕自身 このドメイン駆動設計ですね
この概念というか体系 体系とは言わないかな 概念ですね
ドメイン駆動設計というやり方みたいなもの
これってそういう名付けた何かがなくても
今 例えば僕の所属している株式会社という会社では
普通にシステムを作れてると思います かつそこそこいいものが作れてると思っています
つまりですね このドメイン駆動設計っていう概念を
わざわざ持ち込まなくても 僕が最初に言ったドメイン駆動設計とは何か
というところの一行ですね ビジネスと向き合ってソフトウェアを作る
ということはできると思うんですよ
つまりドメイン駆動設計という言葉が指し示しているもので
ドメイン駆動設計という概念を導入しなくてもできる
というのが今の時点での私の考えです
これは皆さんいろいろ違う意見は あるんじゃないかなと思うんですが
あくまで僕のたどり着いた今の時点の意見ということで
聞いていただければとは思っています
もちろんドメイン駆動設計のパターンの中に
例えばドメインモデルと呼ぶような ビジネスのコア部分というんですかね
ビジネスとは限らないんですけれども
何かソフトウェアとして扱いたい対象の 中心周辺にあるものですね
このあたりのものをソフトウェアの中でも 一番大事だというような扱い方をし
他とは隔離された部分として作ることで
その部分が壊れにくくするだとか
表現として邪魔なものを入れ込まない形で 作れたりするとか
そういうコアドメインというような 作り方があるという感じなんですよね
一時期僕も当然そういったやり方を してきたんですけれども
なんていうんですかね
その作り方をしたソフトウェアが ものすごく価値を発揮したのかというと
それはもう運の世界なのかもしれませんが
何ですかね そのコアドメインという作り方自体が
めちゃくちゃ価値を発揮するかというと
少なくとも今の時点では
なんとなく僕はYesと言えないというか
No寄りな感じがしてるわけです
で どちらかというと
コアドメインみたいな考え方で 分離するというよりは
例えばソフトウェアの設計の世界でいうと
高度のメンテナビリティとか 変更容易性だとか
あとはテストカバレッジとか
そういった話がある中で
より長い期間メンテナンスしやすくするための 技法があるわけですね
そういった技法の立場から大事なものを
メンテナンスしやすい状態にしておくっていうのは
すごく意味があると思うんですけれども
そういった観点を交えずに
単にここがコアドメインだからみたいな理由で
隔離しておくことには
そこまで意味はないんじゃないのかなっていうような気もしています
それにまたちょっと違う観点で
コアドメインについて語るとすると
なんて言うんですかね
コアドメインというか ドメイン駆動設計なのかもしれませんが
なんですかね
これはもう想像でしかないんですけれども
ちゃんとリサーチしたわけではないんですが
このエヴァンさんが
このドメイン駆動設計みたいなアイディアを心に秘めながら
ソフトウェア開発の現場で仕事をしていた頃の
ソフトウェア開発って
おそらく大きなビジネスというか
いわゆるエンタープライズというか
そういった会社ですでに回っている大きな業務
みたいなものがあって
その業務を効率化するみたいな観点で
そういったテーマをもとに
システムが作られるということが
多かった時代なのかなと思うわけですよ
そういった時代であれば
すでにある業務というものを
いかにソフトウェアに
正しく反映させるのかというか
いうところがやっぱり一番大事なことであり
すでにある業務が
ソフトウェアによって置き換わること自体が
ものすごく価値があることだったんじゃないのかな
と思うんですよね
もちろんこれが全てとは言いません
他の革新的なソフトウェアとかも生まれてたと思うので
そういった業務のケースだけが全てではないんですが
エバンスさんの本の中に書いてある例で言うと
どっちかというと業務寄りなので
そういった時代だったんじゃないのかなと思うわけですね
そういった時代には
そのドメインっていうものをしっかり理解し
それをコアドメインとして表現する作り方っていうのが
価値がすごくあったろうなと思うわけですよ
で じゃあ今どういうことを我々はやっているんだろう
というふうに考えた時に
もちろん今でもそういった既存の業務というものを
システムに置き換える
DXなんていう言葉で言われたりするものも
これに含まれるかもしれませんけれども
そういったソフトウェア開発の現場というのは
今でもあると思っています
そういった現場であれば
同じような考え方で
この物事にアプローチすることで
一定の価値はあるのかなと思うんですけれども
一方で 例えば私の現職の会社であれば
なんというんですかね
少なくともどこか既存の業務というのが
ソフトウェアの外側に既にあって
それをソフトウェアにしましょうみたいなことを
やっている会社ではないんですよね
新しく自分たちで
そもそも世の中に存在しなさそうな物事を
事業として形作っていって
もちろんその事業の中には
既存のサードパーティーの方とかと
関わらなければいけない部分が
サブドメインとして存在するんですけれども
メインの事業というところでは
おそらく他に同じものがないようなものを
作っているんですね
っていった時に
それってコアドメインみたいなところに
映し取れるのかっていうと
全くそういう発想では作れないと思っていて
コアドメインの作り方と価値
やっぱりビジネスとして
どう我々がありたいのかっていうところを
しっかりエンジニアの立場からも
ビジネスの人たちと
プロダクトマネージャーとかと
ディスカッションした上で
形を見定めていくっていうことが
必要ですよね
っていうような感じなので
かつそれが
最初にすごく議論して
これが我々のコアだみたいにして
作ったとしましょう
みたいにそれをコアドメインのような
ところに実装したとするんですけれども
必ずしもそのビジネスが
そのままの形で
大当たりしてずっとそのままであるとは
全く限らないわけですよ
むしろそんなことはなくって
もう1ヶ月後2ヶ月後とか
もっと短いスパンで
なんかもうピボットしていく
だったりだとか
変えていかなければいけないというのが
この何て言うんですかね
自社でサービスをやっている
会社のプロダクトとしてはもう
求められる作り方だとするので
そういう世界の物事を
作るのであれば
コアドメインみたいなことは
言ってられないというか
ソフトウェアの作り方の変化
ビジネスがどうあるべきなのか
っていうところに直接向き合って
それに必要な最低限のものを
ソフトウェアとして
作るには何が必要なのか
っていうところを
考え続ける必要がある
という感じだと思うんですよね
もちろん深みが必要な
領域だとかもあるので
そこはバランスを取りながら
しっかり何ですかね
安定したソフトウェアとして
作る部分と
ものすごく早く変化させなければ
ならない部分と
より分けながら作るっていうところが
エンジニアとしての腕の見せ所だ
というのをするわけですけれども
とにかくなんか
コアドメインみたいなところに
意気をしてソフトウェアを
作るということが
あまり価値を発揮しづらい
世の中になってきているんじゃないのかなと
思うわけですよ
長々と話しちゃったんですけど
というところで
そもそもドメイン駆動設計で
提唱された時代とは
だいぶ違うよねっていうところで
もともと言われてた
ドメインモデルみたいなところを
隔離して作ろうみたいなところが
自面通りに解釈して
今ソフトウェアを作ることが
必ずしも正解とは言えないかなと
思っておるところがあったりします
というのが今の時点での
ドメイン駆動設計の考え方
ドメイン駆動設計についての考え方なんで
ちょっとまとめると
何かビジネスと向き合うということは
やっぱり大事なんですよ
そこのコンセプト自体は
僕は間違ってないし
すごく大事だと思っているんですが
じゃあそれの作り方というところで
何かこのコアドメインみたいな
何か概念を導入して
何かそれをうまく作りさえすれば
ビジネスがうまくいくとか
何かちょっとそういった部分は
ちょっと飛躍してる感じもあるし
時代としても違うんじゃないのかなと
思っているので
そこは一歩引いて
自分たちがやろうとしてる
求められてるビジネスに対して
どんなソフトウェアが
必要十分なのか
必要最低限なのか
というところを
冷静に見極められる目の方が
もっと大事だと思っていたりもします
いろいろ話してきたんですけれども
何度も言ってるように
ビジネスと向き合うこと自体は
非常に大事です
これからソフトウェアエンジニアとして
より設計のスキルだとか
そういうところを深めていきたい方が
ドメイン駆動設計を学ぶということが
よくあると思うんですよね
学びなさいと
よく言われてるものだとするので
皆さんがそういう道を通ることは
もう普通なのかなと思うんですが
私個人の意見としては
ドメイン駆動設計というもの自体に
時間を使うのではなくて
それよりもやっぱり大事なのは
ビジネスとどう向き合うのか
つまりビジネスをどう理解するのか
ということだと思っているので
ビジネスを理解するための知識というか
スキルというか
そちら側を学んだ方が
本質的にビジネスと向き合った
ソフトウェア開発をする
というところに到達する近道なのかなと
思うわけですよ
なので例えば
いろんなものがあるんですけれども
ビジネスを理解する上では
例えば財務書評みたいな
会計的な知識があると
役に立ったりだとか
それとは別に
経営論みたいなものの中に
いろんな話があるんですけれども
組織構造に関する話だったり
競争戦略みたいな話だとか
ビジネスモデルの分類みたいな話とかが
あるんですよね
コスト構造がどうなっているとか
そういったところの知識が一定あると
ビジネスとしてどこに
重きを置かなければいけないのか
この会社ではというのが
自分で分かるようになるので
そうであればソフトウェアの設計は
こうあるべきとかね
そういうのが自分で分かるようになる
と思うんですよね
それこそがやっぱり僕は
エンジニアとして
何というのかな
役に立つソフトウェアを作る
設計するための知識として
一番大事なところ
マネージャーと設計方法論
ビジネスと向き合って
ソフトウェアを作るということに
欠かせない知識だと思っているので
そういうところを勉強してみるのも
いいんじゃないかなと思っています
このポッドキャストは
マネージャー向けだったりもするので
最後に一言
マネージャーの方が
どう向き合うのかっていうところの
僕なりの考えを
ヒントみたいなものを示しておくと
こんな感じで
このドメインクの設計みたいなものも
やっぱり時代年月が経つと
考え方をアップデートしなければいけないと
いうふうに思っていたりするわけですよ
なのでこういうソフトウェアの
プラクティスというか
設計方法論みたいなものを
あまり全面に押し出しすぎることはせずに
より本質的に
それぞれ会社さんで
本質というのはちょっとずつ違うと思うんですが
でも本質的に何が求められているのかっていうのを
マネージャーの目線で見極めて
それをエンジニアの一人一人だったり
エンジニア組織に
インストールしていくには
どうしたらいいのかなっていうところで
どういった手法を取るのかだったりだとか
考え方を普及させていくのか
いったところを
ご自分なりに考えていただくと
いいのかなって思ったりしております
はい というわけで
今日はドメイン駆動設計について
私の今の時点での考えっていうのを
お話ししてみました
決してこれが正解ですみたいな形で
普及をしたいわけでもないんですけれども
少なくともマネージャーとして
一定の設計方法論に対する考えみたいなものを
深めておくことって大事だと
するのかなと思っておりますので
これを聞いて何か思うところがあれば
ぜひTwitterでも議論ができたらなと思っておりますので
ぜひご感想などお寄せください
さて この番組では
感想や質問・リクエストなどお待ちしております
番組詳細欄にあるリンクより
お気軽にご投稿ください
Twitterではハッシュタグ
EM問題集をつけてツイートしてください
EMはアルファベット
問題集は漢字でお願いします
そしてApple PodcastやSpotifyのPodcastでは
レビューもできますので
こちらにも感想を書いてもらえると嬉しいです
お相手は株式会社株区スタイル
COO兼CTOの後藤秀之でした
