現職で拙いながらもDDDによる開発を2年間ほどやってみた時の反省点に気づいたのでメモ。
次やる時は「組織的に」足並みを揃えながら開発していきたい。要らん手間が増えるので。
前提
- 1プロダクトを複数チームで開発している。チームは顧客への提供モジュールによる縦割り。（管理画面チームとか、API提供チーム、とか）
- その中の管理画面チームだけでDDDをやって開発した
- いわゆる松岡さんのSUDOモデリング
結果(Problem)
「プロダクト内の一つのデータ（例えば、ユーザ名とか、企業名とか）に対するバリデーションがチーム間で違う」がちょこちょこ起きている。
「管理画面からはユーザ名に記号入れられるけど、バッチ処理による一括登録では入れられない」みたいな感じ。結果、修正箇所が増えて、開発者がちょっと困る。
どうしてそうなった？
- 組織として
- 「ドメイン駆動設計」についてあんまり分かってる人がいなかった。（多分）
- 「とりあえずやってみよう！」で戦術的なDDDのみを導入した（値オブジェクトとか、ドメインエンティティとか、SOLID原則とか）ので、組織としてどうすべきか、みたいな観点がなかった。
- 個人として
- DDD導入当時は組織内での自分の影響力も足りなかった
- 身にしみてメリデメを意識できていなかった（やったことないんだからそりゃそう）
- エイヤでDDDの波に乗っかっちゃった
- 「もうちょっと足並み揃えて練ってからやらない？」っていう頭が全くなかった
- 環境として
- DDDをしていたチームは「画面のリアーキテクチャ」が主な責務だった。それをやりながら他チームとの認識を合わせるとなると、変数が多く、認知負荷が高かったんではないかと思う。
どうすべきだったか？
- 理想的には
- プロダクト全体で「ユーザ名にはこの文字を入れていいですよ」などなどを統一して認識合わせる必要があった
- それをやんなきゃダメだよって組織に対して言える胆力を自分が持っていればよかった
- そうはいっても「組織の流れを変えるのむずい」場合もある。そのときは組織に合わせて上手い落とし所を探すしかなさそう。
次DDD主導するときは、ぜひこの考えを現場に持ち込みたい。
結論
仕事のインパクトを大きくしようとすると人を巻き込む必要がある って話よな〜と思いました。
将来の自分が楽になるために、人を巻き込んで仕事ができるようならなきゃいけないな。。
