Go×TDD/DDDによるリアーキテクチャ半年間の振り返り

Transcript

1. GoとTDD/DDDによるリアーキテクチャ 半年間の振り返り   奥野 志洋
2. 奥野 志洋 新卒2年⽬ 電⾞に乗らなくて良い⼈⽣を求めて エンジニアを志す バックエンドエンジニアとして⼊社し Goをメインに開発 少しNext.jsも 最近はTerraformなども
3. 01 リアーキを始めた理由 02 03 04 05 Agenda 戦略的DDD Goによる戦術的 DDD GoによるTDD DDDとTDDのシナジー
4. サービスの紹介
5. Copyright © DIP Corporation, All rights reserved. リアーキを始めた理由 : 現状の課題と解決策
6. リアーキを始めた理由 : 解決したい課題 複数のシステムが共通の DB、 テーブル、レコードを参照 開発チームも利用者単位で分割 同様のビジネスロジックが各所に 分散、異なる業務ロジックが密結 合している状態
7. リアーキを始めた理由 : 解決したい課題 一つの業務変更が複数の チームに影響を与える 　　　　　↓ 全チームで足並みを揃えて矛 盾が起きないように慎重に開 発するのが状態化
8. 解決するために取り組んだこと : DDDとTDD DDD TDD x 設計面でDDD(ドメイン駆動設計 ) 開発フローとして TDD(テスト駆動開発 )をGoで実践
9. Copyright © DIP Corporation, All rights reserved. 戦略的DDDと戦術的DDD
10. DDD(ドメイン駆動設計) 業務　→　モデリング 戦略的DDD 戦術的DDD モデリング　 →　システム
11. Copyright © DIP Corporation, All rights reserved. 戦略的DDD : イベントストーミング
12. 戦略的DDD : イベントストーミング ドメインエキスパートである POに加え バックエンド、フロントエンド アプリ、インフラのエンジニアが 集まって業務を整理しました。
13. 戦略的DDD : イベントストーミング 思いつく業務イベントを 書き出し時間軸に整理 ビジネスの分割点となる Event (Pivotal Event)を見つける。
14. 戦略的DDD : イベントストーミング Pivotal Eventを元に さらに業務を分解していく 使用者の意思と業務イベントをつなぐ システムを洗い出す コマンド (意思) システム イベント
15. 戦略的DDD : イベントストーミング 整理したイベントに 共通するシステムこそが集約と呼ばれる 業務モデルのまとまりの単位となる 求人を 登録する 求人 求人を 登録した 求人を 削除する 求人を 更新する 求人を 削除した 求人を 更新した
16. 戦略的DDD : イベントストーミング 集約を整理し、境界づけられたコンテキスト (システムの単位 )を発見 その依存関係であるコンテキストマップを作成 →
17. 戦略的DDD : 振り返り 業務を正しい単位で分解 疎結合かつ高凝集なモデル ドメイン知識の獲得 ユビキタス言語の制定 モデリング ドメイン知識
18. Copyright © DIP Corporation, All rights reserved. 戦術的DDD : Goによるモデリング
19. 戦術的DDD : モデルの種類 ・明確な識別子 (ID)を必要とする ・エンティティーは更新可能 例えば「Worker」構造体 エンティティー
20. 戦術的DDD : モデルの種類 ・構成要素の値によって識別されるオ ブジェクト • 識別子(ID)を必要としない • イミュータブルで変更する場合は全 体を置き換える 例えば「支給額」構造体 値オブジェクト
21. 戦術的DDD : モデルの種類 同一のトランザクション境界に 属するエンティティと値オブジェクトの組 み合わせ • 集約もエンティティなので IDが必要 • 集約がトランザクションの単位 集約 値 オブジェクト ワーカー 求人
22. 戦術的DDD : Goによるモデルの表現 ・値オブジェクトは使える時はできる だけ使ったほうが良い ・Goではプリミティブな型にエイリア スとして型を作成できる ・uint64ではなくお金に関するフィー ルドだということがわかるだけで価値 がある。 ・ロジックのカプセル化 値オブジェクト
23. 戦術的DDD : Goによるモデルの表現 Goで集約を実装する際には 紐づくエンティティや値オブジェクト を構造体のフィールドとして定義 また、集約のみが メソッドを外部のパッケージに公開 紐づくフィールドに触れるには集約を通 して行うようにして業務モデルを カプセル化を目指しました。 集約
24. 戦術的DDD : Goの⾔語仕様による課題 ・値オブジェクトの不変制を担保できない ・コンストラクタの使用が強制できない ・privateがない(非exportしても同一パッケージからは触れる ) ・継承が無いので値オブジェクトに同じようなメソッドを 　毎回書く必要がある (Valueメソッドなど ) クラスが存在しないことによる弊害
25. 戦術的DDD : Goの⾔語仕様による課題 クラスが存在しないことによる弊害 左のようにコンストラクタに バリデーションをカプセル化しても 下記のように書けてしまう
26. 戦術的DDD : 振り返り interfaceをうまく使えばコンストラクタを強制することは可能だが、 Goの簡潔に記述する思想と相反する どこまでprivate化してカプセル化を担保するか、どこまで値オブジェクトとして作成 するかなどもそう感じました。 DDDの本に書かれているような定義はあくまで設計思想の一例なので チームでコミュニケーションをとってベストな方法を育てていくのが良い！
27. Copyright © DIP Corporation, All rights reserved. TDD : TDDの基本的な説明
28. TDD : TDDの基本ステップ
29. TDD: TDDのメリット TDDは不確実な事象を小さなステップのサイクルで一歩ずつ確実に進む手法 AIの発展でステップの単位は大きくしながら、安全性を担保することが可能に ・小さな単位なので指示が明確 ・テストコードがプロンプト ・生成コードをその場で検証可能 ・レビューの負担減少 AI活用による生産性向上 安全性の担保
30. Copyright © DIP Corporation, All rights reserved. TDD : GoでTDDを行う際のポイント
31. TDD: テストパターンの使い分け 開発時にテーブル駆動テストではなくAAAパターンのテストを採⽤ Arrenge (準備) Act (実行) Assert (検証)
32. TDD: テストパターンの使い分け 開発時にテーブル駆動テストではなくAAAパターンのテストを採⽤ テストケースが他のテストケースに依存しない形になる TDDのサイクルを回す中で詳細化していくテストケースやテスト観点に対応可能 下記のような使い分けで GoによるTDDを実践していきました。 機能開発時に TDDのステップでスピード高く開発していく際には AAA 機能実装後に、品質を高めるためのテストを追加する際にはテーブル駆動
33. Copyright © DIP Corporation, All rights reserved. DDD と TDD のシナジー
34. DDDとTDDのシナジー DDD x TDD x AI ・DDDによる責務が分割された業務モデル簡潔化されたロジック ・ユビキタス言語をリポジトリ内で管理 ・型も値オブジェクトを用い、業務で使われる共通言語を使用 ・生成AIと相性の良い TDDの開発フロー
35. DDDとTDDのシナジー 構造化された t.Run()のテストケースが 業務の⾔葉で書かれて 動く仕様書に
36. Copyright © DIP Corporation, All rights reserved. まとめ
37. まとめ Goの⾔語仕様では完全な業務のカプセル化はできないが、 チームで認識を合わせて⾃分たちにあったルールや開発フローを 定めていくことが重要 テストを書く意味を考えてAAAパターンとテーブル駆動テストを 使い分けることでTDDのサイクルのスピードを⾼めて開発ができた
38. Copyright © DIP Corporation, All rights reserved. より深い話は懇親会などで！ ご清聴ありがとうございました！！！