DDDにどう立ち向かう？リファクタリングのあれこれ

2022/9/29 3社合同DDD勉強会

Transcript

1. DDDにどう立ち向かう？ リファクタリングのあれこれ 2022/09/29 株式会社Voicy 灘脇裕一 (@natacoon)
2. 自己紹介 灘脇 裕一 Backend Engineer 機能開発チームリーダー スクラムマスター 2012.04 - HRTech 2020.07 - Voicy 本日はよろしくお願いします！ @natacoon 好きなモノ: 服とねことスプラトゥーン 株式会社Voicy
3. 本日のアジェンダ 影響範囲への意識を極力なくす 1 ２ リファクタリングすべきはなにか
4. Voicy
5. Voicy 声で人の視界を広げ、ワクワクする社会へ。 たのしい声。せつない声。くやしい声。うれしい声。
 ここに来れば、パーソナリティは本音を語ることができ、リス ナーは本音を聞くことができる。
 
 そんな、声のプラットフォームを築くことで、人の視界は広が り、ワクワクする社会が生まれていく。2016年の創業以来、私 たちのこの想いは変わることはありません。
 
 そのために、これからもVoicyは進化し続けます。
6. Voicy プロダクト
7. 本日のアジェンダ 影響範囲への意識を極力なくす 1 ２ リファクタリングすべきはなにか
8. 前段 - もともとDDDは全くやっておらず、手続き的なコードが増えてきた - 以前はプロダクトに備えている機能はシンプルだったので、問題はなかった - が、徐々にプロダクト・開発組織も大きくなり始めたことにより、システムが実現しようと していることがコードから読み取りづらくなってきていた - 会社全体で概念レベルの理解がズレはじめていた ①のスライド ②のスライド
9. 前段 今日の内容は Voicyで今後どうしていこうかを私が模索している 構想の途中経過を切り取って話してみる という回です
10. リファクタリングすべきはなにか
11. リファクタリングすべきはなにか ユーザーストーリーマッピング ユースケース ドメインモデル（概念レベル） モデリングはPdM、デザイナーとともにやってきている
12. リファクタリングすべきはなにか よーし、じゃあリファクタリングするぞ！
13. リファクタリングすべきはなにか どこから・・・？
14. リファクタリングすべきはなにか そもそもリファクタリングって？ - マイクロリファクタリング - パターン指向リファクタリング - ドメインのリファクタリング（より深いモデルへのリファクタリング） エリック・エヴァンスのドメイン駆動設計 第3部 より深い洞察へ向かうリファクタリ ング より
15. リファクタリングすべきはなにか マイクロリファクタリング、パターン指向リファクタリングは技術的な観点から設計 の質を高める コードが何をしているかを理解しやすくする
16. リファクタリングすべきはなにか ドメインのリファクタリングは、ドメインに対する深い洞察をモデルに反映させる コードがなぜそれを行うのかをモデルに適用し、コードがなぜそうなっているのかを 明らかにする
17. リファクタリングすべきはなにか What → マイクロリファクタリング、パターン指向リファクタリング Why → ドメインのリファクタリング
18. リファクタリングすべきはなにか 事業としてプロダクトを成長させていくにあたって 本当に行いたいのはドメインのリファクタリング
19. リファクタリングすべきはなにか ドメインのリファクタリングにより モデルからさらなる洞察を行い、事業価値を高めるモデルを探求する活動を促進する これにより企業の活動を成長体質に変化させる
20. リファクタリングすべきはなにか とはいえ、ドメインのリファクタリングはたいていの場合において 一連のマイクロリファクタリングを伴う
21. リファクタリングすべきはなにか そのため、まずやるべきは マイクロリファクタリング、パターン指向リファクタリング
22. リファクタリングすべきはなにか どこから・・・？
23. リファクタリングすべきはなにか DDDを駆動している原則 - コアドメインに集中すること - ドメインの実装者とソフトウェアの実践者による創造的な共同作業を通じて、モ デルを探求すること - めいじてきな境界づけられたコンテキストの内部で、ユビキタス言語を語ること
24. リファクタリングすべきはなにか 極端にいえば、コアドメインさえモデルに準じた実装がされ、変更容易性を担保でき れば、事業価値を高める体質に変化させることはできる
25. リファクタリングすべきはなにか 書ききれなかったこと（ゴメンナサイ🙏） - コンテキストマップを作成してコアドメインを探す
26. 影響範囲への意識を極力なくす
27. 影響範囲への意識を極力なくす というか、まだそのモデルを適用できる状態ではないんだけど・・・
28. 影響範囲への意識を極力なくす 大事な箇所だからこそ実装が込み入っていて手をつけるのが怖いし アーキテクチャにも課題があるんだけど・・・
29. 影響範囲への意識を極力なくす 既存の実装を残しつつリファクタリングしてみない？
30. 影響範囲への意識を極力なくす リファクタリングとは、コンピュータプログラミングにおいて、プログラムの外部か ら見た動作を変えずにソースコードの内部構造を整理することである。 Wikipedia より
31. 影響範囲への意識を極力なくす つまり、既存コードすべてに手を加える必要はなく、既存を捨てつつ置き換えること もある（当たり前だけども） ＝捨て去るのはメソッド、クラス、はたまたユースケース実装ごとなど、置き換える 単位は様々 （マイクロサービスへの移行なども、大きな見方をすればリファクタリングの一部と 考えられる）
32. 影響範囲への意識を極力なくす 例えば・・・ APIインターフェースを変えないけど、内部のアーキテクチャから見直したい
33. 影響範囲への意識を極力なくす アプリケーションレイヤ以降を置き換えてみる
34. 影響範囲への意識を極力なくす アプリケーション層のユースケース（サービス）ごと新規に実装し、プレゼンテー ション層からの呼び出しを切り替える （＝既存コードを残したままにする）
35. 影響範囲への意識を極力なくす いろんな粒度でのストラングラー（アプリケーション）を作っていく ビッグバンリライトを避けてリスクを軽減する マイクロサービスパターン Chapter13 1.2 モノリスを絞め殺す より
36. 影響範囲への意識を極力なくす 「ビッグバンリライトが生み出すのはビッグバンだけ」 マーチン・ファウラー
37. 影響範囲への意識を極力なくす デメリット - 捨てる予定のコードに新規機能が実装されてしまうとそのまま負債になる - いずれ再実装することになるので、開発にかける時間ももったいない
38. 影響範囲への意識を極力なくす Kubernetes上に各種サービスが稼働してる おまけ: デプロイのはなし
39. 影響範囲への意識を極力なくす カナリアリリースとして、1Podだけ既存のnamespaceのdeployment管理下にリファクタリング 後の呼び出しに変更した実装を適用したPodを配置する おまけ: デプロイのはなし リファクタ版
40. 影響範囲への意識を極力なくす エラーが一定以上起こるようであればPodを取り除く おまけ: デプロイのはなし リファクタ版
41. まとめ - コアドメインを見つけて（定義して）集中しよう！ - 一定以上大きいリファクタリングはストラングラーパターンを使って、既存 コードへの大きい変更を避けてみよう！
42. 参考
43. お知らせ Meetyでカジュアル面談をやってます！ 転職関係ない話もウェルカムなのでお話しましょう URL: https://meety.net/matches/KjRwJrKGDbKO Voicy ダウンロードリンク