こちらのイベントに参加して学びがあったので忘れないうちに記録に残します。
コミューン株式会社さんと株式会社ログラスさんの2社でDDDの活用方法についてパネルディスカッションをする会でした。コミューン株式会社オフィスで開催するオフラインイベントで、自分にとってはコロナ明けて初めてのオフラインイベントでした。
参加の目的
自分は来週新しい会社で働きはじめます。現職はメーカー企業でソフトウェアエンジニアをしており、担当プロジェクトにDDDを導入してきました。
新しい会社はスタートアップ企業で自分が所属するプロジェクトはまだリリースされていない段階です。おそらくDDDは導入していないと思われますが、DDDを導入するかの判断基準や、スタートアップにおけるDDDのメリットを知れればと思い参加しました。
パネルディスカッション
今現在の開発テーマや組織の状況、DDDの取り組み状況について
- コミューン
- 去年、軽量DDDをやろうという流れがあり、これからDDDを本格的に取り入れる段階
- ログラス
コミューンさんも話していましたが、軽量DDDにも良さがある一方、やはり複雑な事業でモデリングをしてこそDDDが真価が発揮されるのだなと改めて感じました。
※ 軽量DDD: DDDのValueOvject、Entity、Repositoryなど技術的な部分のみを取れ入れDDDを行うこと
DDDをはじめようと思ったきっかけ
- コミューン
- コミュニケーションの齟齬が大きくなってきた
- チームが機能ごとではなく割と適当に2チームに分かれている。それをしっかりコンテキストを認識して是正したい
- ログラス
- ドメインエキスパートであるCEOと共通言語が必要
- コードはレビューできないが、モデルはレビューできる
- データモデルだけは変わらないけど、ピボットが何回も起こることを考えてDDDを導入
増田さんから以下の話もありました。※ 勝手に引用すみません
Q. DDDが成功する要因は？
— 大西 政徳 | InnoScouter CTO (@monarisa_masa) 2023年6月15日
A.
①今のコードになんとかしたいとチーム全体が思っている状況
(コードに対しての捉え方はメンバーそれぞれなので、それがまず揃っている)
②いい方向に行けるという期待値が揃っている状況
(DDDをどの方向にどれだけやっていくかの認識が揃っている)#startup_ddd
ログラス社の「コードはレビューできないが、モデルはレビューできる」という言葉を聞いて妙に納得できました。
ただ入社してすぐに無理やりDDD導入すると失敗するでしょう。転職先はまだプロダクトもリリースされていないのでDDD導入がまだしやすい時期だと思いますが(?)、増田さんが話されていたようにチーム全体で話し合って必要があれば進めていきたいです。
DDDを導入してから組織に広げていく過程の課題
- コミューン
- エンジニアだけで閉じているとうまくいかない
- PdMにDDDの理解をしてもらう必要がある
- ログラス
- 最初はServiceクラスを撲滅して、usecaseに書き換えることから始めた。(実装から入って、モデリングは後でやった)
- 設計の検討事項やプログラミング言語のこれが良いなどのベストプラクティス集のような設計標準を用意している
- 設計標準は、絶対に従わなければいけないわけではない。後から来た人にもWhyがわかるようになっている
- 設計標準については、アート・オブ・アジャイル デベロップメント に書いてある
ログラスさんのユースケースやドメインのリファクタリングから始めて、周りにコードの見通しの良さを広めることはどこの会社でもできそうですし有効な手段だなと感じました。その後。新機能の開発からモデリングや集約の設計を行うことは、合理的で実践しやすそうなのでやっていきたいです。
所感
目的であった転職先でのDDD活用は、実際に事業がどれだけ複雑か、共通言語ができていないなど課題があれば前向きに導入を検討したいと感じました。(無理に導入する必要もない)
途中で増田さんが話されていた、モデリングで仮説を出したら、実際に実装をしフィードバックを受ける。そしたら再度モデリングといった 「モデリング→実装→フィードバック→モデリング」を高速で繰り返していくことが何よりも大事だと感じました。
上を実践する上で、松岡さんが話されていた（アート・オブ・アジャイル デベロップメントに記載のある）「リファクタリングは絶え間なくする」は心に刻んでおきたいと思います。
最後に
懇親会ではピザ食べれました🍕ごちそうさまでした。
抜け漏れ、間違いあるかもしれませんが、ご容赦ください。 当日参加されていた方で、明らかな間違いに気づいた点があればコメントください。
