そろそろドメイン駆動設計はもうちょっとだけ細分化されるべき

昨日飲みながらドメイン駆動設計（以下、DDD）についてしゃべっていて思ったことを書く。

ドメイン駆動設計（DDD）って？

DDD とは何かという説明についてはぐぐったらたくさん出てくると思うので割愛。

Wikipedia の引用だけしておきます。（雑）

ドメイン駆動設計 - Wikipedia

ドメイン駆動設計（英: Domain-driven design, DDD）とはソフトウェアの設計手法であり、'複雑なドメインの設計はモデルベースで行うべきであり'、'また大半のソフトウェアプロジェクトではシステムを実装するための特定の技術ではなくドメインそのものとドメインのロジックに焦点を置くべき'とする。この名称は Eric Evans が同名の著作で用いた。

興味がある人はこちらを読んでください。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

実践ドメイン駆動設計 (Object Oriented Selection)

実践ドメイン駆動設計 (Object Oriented Selection)

ソフトウェア設計手法としての DDD

僕は DDD を最初ソフトウェアの設計手法として学んだ。ソフトウェア設計というと表現が大袈裟かもしれないけど、要は今自分の目の前にあるコードベースがもっと綺麗でメンテしやすい形であって欲しいという願いが第一義的だった。

当時僕はとある業務システムをやっていたのだけどそのプロジェクトでは「このボタンを押したときにサーバとの通信が発生して性能的に（以下略」とか「データベースにはこういうデータを保存しているのでその要件を満たすためには（以下略」とか「ブラウザのクッキーに（以下略」とか到底ユビキタス言語のユの字も出てこないようなコミュニケーションをやっていて、エンジニアと非エンジニアのコミュニケーションコストがすごく高かった（ように感じた）。

ただ当時の僕はこのチームのコミュニケーションをもっと円滑したいなんていう高尚なことを考えていたわけではない。ただ目の前にあるコードがどんどん自分の理想から離れていくのが我慢できなかっただけだ。円滑ではないコミュニケーションに引っ張られて要求はどんどん複雑化し、仕様は変わり、それにアドホックに対応した形跡がコード中に散見されるという状態で、僕はこれではこのプロジェクトを嫌いになってしまいそうだなと思ってしまったことが DDD を学ぶきっかけだった。

だから僕はかなり実装に近い立場でエリック・エヴァンスの DDD 本を読んだ。

エンティティとバリューオブジェクトは何が違うのか、サービスとは何か、仕様パターンは何が嬉しいのか、ファクトリーとかポリシーとかもあるのか、そういうところが僕が最初に DDD 本を読んだときの興味だったし、その流れでそもそも自分はオブジェクト指向をちゃんと理解してなかったような気がして別の書籍をあたったりもした。

まあ、ただそれだけだったら DDD 本はただのデザインパターン本ということになってしまうしそれだったら GoF でも読んでろよという話で、それはそうだと今なら本当に思うんだけど、当時の僕はこんな感じだったんだというお話。

組織論としての DDD

これは最近思っていることだけど、ドメインの分析の成果として適切な大きさのチームへの分割があると思う。DDD 本にあるパターンでいうと「境界づけられたコンテキスト」とか「コンテキストマップ」とかがそうだ。

ある程度システムが複雑になってくるとそこに複数のコンテキストが存在することが多くなる。その場合、無理にドメインモデルを統合するのでなく、コンテキストに明確な境界を設定しコンテキストごとに別々のモデルを構築したり、異なるドメインモデルの接点を明確にしたりすることで、全体が大規模かつハイコンテキストになってもメンテナンスしやすい大きさのチームやプロセスやアーキテクチャを保つことができる。これは DDD の大きな価値である。

これについては昨年末くらいからよく言葉を聞くようになったマイクロサービス（microservices）と似てる。システムが大規模になった場合、それは小さいサービスに分割したほうが個々のシステムはシンプルに保つことができるがサービス間のインターフェースが増えるとそこで問題が起こりやすくなるし、それを防ぐためのコミュニケーションが必要になってしまう。なので、マイクロサービスはどういう単位で分割するかというのが非常に大事であり、個々のサービスのアーキテクチャ以上にサービス間のインターフェースやそこで生じるコミュニケーションの設計に気を遣わないといけない。

それらの方法論を「境界づけられたコンテキスト」「コンテキストマップ」というパターンで提供しているのが DDD であり、つまり DDD とは組織パターンであると捉えることができる。

DDD の話は DDD だけにとどまらない

DDD の話をしているともっと広く話が盛り上がってしまうことが多い。

DDD 自体が設計手法や分析手法でもあり、組織論でもあり、どういう立場でそれを捉えるかによって本質が異なってくるようなものなので当然かもしれない。

最近、 DDD はとても流行っているように思う。Twitter や誰かのブログで毎日のように DDD の話題を目にするし、現場に導入してるという話もそれなりに聞く。コミュニティとしては十分に盛り上がってきたのではないかと思う。

そんな今だからこそ、もう少し掘り下げた議論をし始めるべきではないか。エリック・エヴァンスの DDD から僕らはたくさんのことを学んだけど、もっと実践的に、もっと他の知識と組み合わせてその効果を最大化する余地が DDD にはあると思う。

個人的には

あたりは結構盛り上がりそうだな、と思っている。