ドメイン駆動設計を学んでいろいろと腑に落ちた話

こんにちは。事業開発チームの嶋田と申します。

ドメイン駆動設計とは

まずはドメイン駆動設計(以下 DDD)の軽くおさらいです。DDDはソフトウェアで解決する領域をエンジニアや非エンジニアが共通の言語を持ち、共通の言語からそのままプログラムのコードへ反映することで、ビジネス価値や生産性の向上を一体となって目指す設計手法です。

弊社に最適解だった

基本的なエンジニアの業務フローとして営業・マーケティング職等の方から上がってくる課題等をエンジニアがコミュニケーションを取りながら実現していくというのがよくある形であったのですが、エンジニアサイドからの視点のみで設計しても、非エンジニアの業務フローが複雑化していてるケースに対応できていない課題がありました。例えばAという機能をリリースしたが、時間の経過とともに機能が不足することになりその不足分を人的リソースでカバーしていたり、A機能についてエンジニアに相談して改修して部分的には効率化ができたけど非エンジニアの全体の業務が見えておらずあとから別件で改修するときにボトルネックになっていた等、効率が少しずつ落ちていきました。

DDDはこの問題に対する一つの解かと思います。

DDD用語を駆使して上記の問題点を言うと、ドメインエキスパートが不在なため最適なコアドメインの選出と最適なドメインモデルを作り続けることができていないということになるかと思います。

最適なコアドメイン・ドメインモデルを作り続けるとは

会社の戦略や方針についてエンジニアチームというのは特にビジネスチームとエンジニアチームが明確に別れているのであれば、それについての対応が遅れがちになるかと思います。

ですが、適切なDDDが設定されているのであれば、会社の方針にアップデートがあった場合は即座に注力すべきことや、これまで作ってきたものの取捨選択の議論がエンジニアを含んで議論が可能になるはずです。

すなわちより無駄な開発というのが少なくなります。

特にベンチャー企業だと最適なコアドメイン・ドメインモデルを作り続けることが困難

人が入れ替わる

入社退社や配置換えなどはよくあることです。ドキュメントの共有や引き継ぎ等はどこの会社でも行われているかと思いますが、どういう意図でそういう事になったのかといった当時の背景等は徐々に薄まります。

集中する領域がよく変わる

会社の方針によりビジネスモデルが変わったり、収益となるポイントが徐々にずれていったりしていきます。

どれがあたるかわからない

作っては捨てを繰り返すので、スモールスタートというのは普通かと思いますが、どこまでを想定して設計するかの取捨選択が難しい。

とはいえDDDがすべてを解決する銀の弾丸ではないです

会社によってそれまでに様々な事情があり、人的リソースの問題もあります。特に非エンジニアを巻き込みつつやっていくには高いハードルがあります。

また、正解なモデルというのは存在しないので、常に改善していく必要があります。

個人的なところとしては、MVC フレームワークへDDDを落とし込むのにどうしても違和感が発生してしまうというのはあります。このあたりは折り合いをつけていくしかないのかなと感じています。

まとめ

数年前に現在の担当している領域に途中から参加したのですがしばらく開発してみて感じていたのが、ビジネスチームと一体となっていやっているはずだけど拭えない非効率感でした。

DDDは自分の感じていた非効率感を一つの軸をつくりそれをベースに議論できる拠り所になると感じています。