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

Slide 1

Slide 1 text

GoとTDD/DDDによるリアーキテクチャ半年間の振り返り奥野志洋

Slide 2

Slide 2 text

奥野志洋新卒2年⽬電⾞に乗らなくて良い⼈⽣を求めてエンジニアを志すバックエンドエンジニアとして⼊社し Goをメインに開発少しNext.jsも最近はTerraformなども

Slide 3

Slide 3 text

01 リアーキを始めた理由 02 03 04 05 Agenda 戦略的DDD Goによる戦術的 DDD GoによるTDD DDDとTDDのシナジー

Slide 4

Slide 4 text

サービスの紹介

Slide 5

Slide 5 text

Slide 6

Slide 6 text

リアーキを始めた理由 : 解決したい課題複数のシステムが共通の DB、テーブル、レコードを参照開発チームも利用者単位で分割同様のビジネスロジックが各所に分散、異なる業務ロジックが密結合している状態

Slide 7

Slide 7 text

リアーキを始めた理由 : 解決したい課題一つの業務変更が複数のチームに影響を与える　　　　　↓ 全チームで足並みを揃えて矛盾が起きないように慎重に開発するのが状態化

Slide 8

Slide 8 text

解決するために取り組んだこと : DDDとTDD DDD TDD x 設計面でDDD(ドメイン駆動設計 ) 開発フローとして TDD(テスト駆動開発 )をGoで実践

Slide 9

Slide 9 text

Slide 10

Slide 10 text

DDD(ドメイン駆動設計) 業務　→　モデリング戦略的DDD 戦術的DDD モデリング　 →　システム

Slide 11

Slide 11 text

Slide 12

Slide 12 text

戦略的DDD : イベントストーミングドメインエキスパートである POに加えバックエンド、フロントエンドアプリ、インフラのエンジニアが集まって業務を整理しました。

Slide 13

Slide 13 text

戦略的DDD : イベントストーミング思いつく業務イベントを書き出し時間軸に整理ビジネスの分割点となる Event (Pivotal Event)を見つける。

Slide 14

Slide 14 text

戦略的DDD : イベントストーミング Pivotal Eventを元にさらに業務を分解していく使用者の意思と業務イベントをつなぐシステムを洗い出すコマンド (意思) システムイベント

Slide 15

Slide 15 text

戦略的DDD : イベントストーミング整理したイベントに共通するシステムこそが集約と呼ばれる業務モデルのまとまりの単位となる求人を登録する求人求人を登録した求人を削除する求人を更新する求人を削除した求人を更新した

Slide 16

Slide 16 text

戦略的DDD : イベントストーミング集約を整理し、境界づけられたコンテキスト (システムの単位 )を発見その依存関係であるコンテキストマップを作成 →

Slide 17

Slide 17 text

戦略的DDD : 振り返り業務を正しい単位で分解疎結合かつ高凝集なモデルドメイン知識の獲得ユビキタス言語の制定モデリングドメイン知識

Slide 18

Slide 18 text

Slide 19

Slide 19 text

戦術的DDD : モデルの種類・明確な識別子 (ID)を必要とする・エンティティーは更新可能例えば「Worker」構造体エンティティー

Slide 20

Slide 20 text

戦術的DDD : モデルの種類・構成要素の値によって識別されるオブジェクト • 識別子(ID)を必要としない • イミュータブルで変更する場合は全体を置き換える例えば「支給額」構造体値オブジェクト

Slide 21

Slide 21 text

戦術的DDD : モデルの種類同一のトランザクション境界に属するエンティティと値オブジェクトの組み合わせ • 集約もエンティティなので IDが必要 • 集約がトランザクションの単位集約値オブジェクトワーカー求人

Slide 22

Slide 22 text

戦術的DDD : Goによるモデルの表現・値オブジェクトは使える時はできるだけ使ったほうが良い・Goではプリミティブな型にエイリアスとして型を作成できる・uint64ではなくお金に関するフィールドだということがわかるだけで価値がある。・ロジックのカプセル化値オブジェクト

Slide 23

Slide 23 text

戦術的DDD : Goによるモデルの表現 Goで集約を実装する際には紐づくエンティティや値オブジェクトを構造体のフィールドとして定義また、集約のみがメソッドを外部のパッケージに公開紐づくフィールドに触れるには集約を通して行うようにして業務モデルをカプセル化を目指しました。集約

Slide 24

Slide 24 text

戦術的DDD : Goの⾔語仕様による課題・値オブジェクトの不変制を担保できない・コンストラクタの使用が強制できない・privateがない(非exportしても同一パッケージからは触れる ) ・継承が無いので値オブジェクトに同じようなメソッドを　毎回書く必要がある (Valueメソッドなど ) クラスが存在しないことによる弊害

Slide 25

Slide 25 text

戦術的DDD : Goの⾔語仕様による課題クラスが存在しないことによる弊害左のようにコンストラクタにバリデーションをカプセル化しても下記のように書けてしまう

Slide 26

Slide 26 text

戦術的DDD : 振り返り interfaceをうまく使えばコンストラクタを強制することは可能だが、 Goの簡潔に記述する思想と相反するどこまでprivate化してカプセル化を担保するか、どこまで値オブジェクトとして作成するかなどもそう感じました。 DDDの本に書かれているような定義はあくまで設計思想の一例なのでチームでコミュニケーションをとってベストな方法を育てていくのが良い！

Slide 27

Slide 27 text

Slide 28

Slide 28 text

TDD : TDDの基本ステップ

Slide 29

Slide 29 text

TDD: TDDのメリット TDDは不確実な事象を小さなステップのサイクルで一歩ずつ確実に進む手法 AIの発展でステップの単位は大きくしながら、安全性を担保することが可能に・小さな単位なので指示が明確・テストコードがプロンプト・生成コードをその場で検証可能・レビューの負担減少 AI活用による生産性向上安全性の担保

Slide 30

Slide 30 text

Slide 31

Slide 31 text

TDD: テストパターンの使い分け開発時にテーブル駆動テストではなくAAAパターンのテストを採⽤ Arrenge (準備) Act (実行) Assert (検証)

Slide 32

Slide 32 text

TDD: テストパターンの使い分け開発時にテーブル駆動テストではなくAAAパターンのテストを採⽤テストケースが他のテストケースに依存しない形になる TDDのサイクルを回す中で詳細化していくテストケースやテスト観点に対応可能下記のような使い分けで GoによるTDDを実践していきました。機能開発時に TDDのステップでスピード高く開発していく際には AAA 機能実装後に、品質を高めるためのテストを追加する際にはテーブル駆動

Slide 33

Slide 33 text

Slide 34

Slide 34 text

DDDとTDDのシナジー DDD x TDD x AI ・DDDによる責務が分割された業務モデル簡潔化されたロジック・ユビキタス言語をリポジトリ内で管理・型も値オブジェクトを用い、業務で使われる共通言語を使用・生成AIと相性の良い TDDの開発フロー

Slide 35

Slide 35 text

DDDとTDDのシナジー構造化された t.Run()のテストケースが業務の⾔葉で書かれて動く仕様書に

Slide 36

Slide 36 text

Slide 37

Slide 37 text

まとめ Goの⾔語仕様では完全な業務のカプセル化はできないが、チームで認識を合わせて⾃分たちにあったルールや開発フローを定めていくことが重要テストを書く意味を考えてAAAパターンとテーブル駆動テストを使い分けることでTDDのサイクルのスピードを⾼めて開発ができた