DDD実装におけるチームの正解を見つける話

この記事はCalendar for WHITEPLUS | Advent Calendar 2022 - Qiitaの 7日目の記事です。

はじめに

こんにちは、ホワイトプラスのWeb開発チーム所属でエンジニアをしている德廣です！
ホワイトプラスには今年の3月に入社、この記事は入社2ヶ月目ぐらいのオンボーディングの一貫として取り組んだ話です。

この記事では「DDD実装におけるチームの正解を見つける話」としてお話しますが、「異なる背景で学び実践してきた技術（つまり前職の技術）を、チームで活かすための話」としても読んでいただけるかと思います。

背景

（弊チームではDDD（ドメイン駆動設計）を採用しています。）

突然ですが、 "ValueObject（値オブジェクト）" や "Repository（リポジトリ）" について説明を求められた時、所属しているチームメンバーと「同じ話」ができるでしょうか？

転職してすぐの私にはできませんでした。
DDDに限らず「前職（前配属先）のチームでは別の解釈をしていました」というのはよくある話だと思います。
※背景や環境（学んできた経緯や実践してきた場）が異なるため、当然。

そしてこの 解釈やこれまでの経験との違い によって、レビューの指摘で手戻りが発生したり、既存コードについての確認などで度々チームの時間が奪われてしまっていました。

早くチームに貢献したいという焦りもあった私は「 チームの正解（目指す設計・実装） を明確にすれば、新たな参画メンバーでも自分のブレに気付けるし最速でチーム貢献できるようにのでは？」と思い、 チームの正解（目指す設計・実装） を探すには "チームメンバーそれぞれが考える理想" をブツけるのが早いと考え "DDD認識共有会" を開催することにしました！

"DDD認識共有会" の開催

やること

共有会の内容はシンプルです。

メンバーの一人が自身の解釈や理解していることを、こんな感じで話すだけ。
- 「そもそもDDDとは？その目的とは？」
- 「Aggregate（集約）とは？その責務は？一番理想に近い既存コードは？」
誰が話すのか？
- 德廣が話し手になりました。（理由は後述）

ゴール

チームとして
- チームの正解（目指す設計・実装） を見つける。
メンバー個人として
- 普段の疑問や悩みを積極的に発言し、より良い設計・実装を模索する。
  - 「こういう風に実装しているところを見つけたけど、自分なら別のアプローチがいいと思う。みんなはどう？」
  - 「こんな問題が出てきたんだけど、こんな時どうしてる？」
- DDD歴が浅いメンバーは理解を深める機会とし、疑問があれば解消する。
  - 「なるほど、わからん」も積極的に発言してもらう。

やってよかったこと

当初の問題点であった「時間が奪われる」ことが減った。
- チームの正解（目指す設計・実装） を把握しているため、実装時に迷いがなくなった。
- キャッチアップの速度が早まったと実感しています。
思わぬ効果
- レビュワー間の方向性の違いによる議論が減った。
DDD歴が浅いメンバーの理解が深まった。
- 既存コードに対して「チームの正解（目指す設計・実装） と違うかも？」と、疑問を持てるようになった。
- 数カ月後に「共有会の時にみんなが話してたことがやっとわかりました」などの成長が感じられるようになった。
より浸透させる施策のきっかけができた。
- DDD歴が浅いメンバーがどのような点で躓きやすいかがわかったので、次のステップとして「パターン毎の実装ガイドライン作成」の施策を取り組みはじめました。
  - 「責務と役割と、その実現する方法」「実装のポイント」「実装例」をパターン毎にまとめています。
    
    実装ガイドライン-ユースケース-実装例の一部