脱軽量DDDを実践する開発プロジェクトの事例 / Examples of development projects that practice de-lightweight DDD

by Yappli Developers

Slide 1

Slide 1 text

脱軽量DDDを実践する開発プロジェクトの事例

Slide 2

Slide 2 text

Speaker プロダクト開発本部サーバーグループ窪田修 Kubota Shu キャリアスタートはReact, React Native。ヤプリに 2022年5 月にサーバーサイドエンジニアとして入社。特に、DDD、hooks設計、Redux設計が好き。ヤプリでは主にGo, PHPでのサーバーサイドアプリケーションの設計, 開発を担当。一部インフラの整備、Webフロントエンドの開発もたまにする。業務ではAWSがほとんどだったが、最近Google Cloudの資格をとって Google Cloudにハマりつつある。

Slide 3

Slide 3 text

Agenda Yappliのシステムの概要なぜDDDで設計したのか軽量DDDになるという課題軽量DDDになる要因脱軽量DDDのアプローチ PJの事例実践モデリング戦術的DDDの知見まとめ 00 01 02 03 04 05 06 07 08

Slide 4

Slide 4 text

今日の話のサマリー YappliのサーバーサイドのシステムはDDDで設計されている。一方で軽量DDDになるという課題がある。そこで1開発PJで脱軽量DDDの設計事例を作った。プロダクト全体の脱軽量DDDの取組みを継続している。

Slide 5

Slide 5 text

00 Yappliのシステムの概要

Slide 6

Slide 6 text

0 0 Yappliのシステムの概要システムの概略

Slide 7

Slide 7 text

0 0 Yappliのシステムの概要システムの概略 DDDͰઃܭ

Slide 8

Slide 8 text

0 0 Yappliのシステムの概要システムの概略 DDDͰઃܭ

Slide 9

Slide 9 text

01 なぜDDDで設計したのか

Slide 10

Slide 10 text

զʑͷ໨త͸Կ͔ʁ

Slide 11

Slide 11 text

៉ྷͳγεςϜΛ࡞Δ͜ͱ

Slide 12

Slide 12 text

៉ྷͳγεςϜΛ࡞Δ͜ͱ ビジネス的価値を継続的に届けるシステムを作ること

Slide 13

Slide 13 text

΋͏গ͠ϒϨΠΫμ΢ϯ͢Δͱ

Slide 14

Slide 14 text

໨త = ϝϯςφϯεੑ͕ߴ͘ɺ εέʔϧ͢ΔγεςϜΛ࡞Δ

Slide 15

Slide 15 text

खஈͱͯ͠ෳࡶͳ࢓༷ͷઃܭʹదͨ͠ DDDΛ࠾༻ͨ͠

Slide 16

Slide 16 text

01 なぜDDDで設計したのか今日の話の前提知識 • エリック・エヴァンスのドメイン駆動設計 • 実践ドメイン駆動設計 • ドメイン駆動設計モデリング/実装ガイド • ドメイン駆動設計入門

Slide 17

Slide 17 text

Domain Driven Design(DDD)とは • ドメインモデルを中心とした設計パターン • ドメイン知識そのものをコード上に表現することを目指す 01 なぜDDDで設計したのか

Slide 18

Slide 18 text

DDDの得意なこと • 複雑な仕様をモデルの振る舞いとして表現できる • ドメイン知識そのものをソースコードとして表現できる • 結果的に複雑なソフトウェアを継続的に誰でもメンテナンスできるようになる 01 なぜDDDで設計したのか

Slide 19

Slide 19 text

DDDの得意なこと • 複雑な仕様をモデルの振る舞いとして表現できる • ドメイン知識そのものをソースコードとして表現できる • 結果的に複雑なソフトウェアを継続的に誰でもメンテナンスできるようになる →ϊʔίʔυͰΞϓϦΛ࡞ΕΔYappliͷCMSͷػೳ͸ଟ͘ɺ࢓༷͸ඇৗʹෳࡶͰ ͜ΕΛ࣮ݱ͢Δखஈͱͯ͠DDDͰͷઃܭ͸ྑͦ͞͏ 01 なぜDDDで設計したのか

Slide 20

Slide 20 text

ҰํͰDDDʹ͸σϝϦοτ΋͋Δ

Slide 21

Slide 21 text

DDDの苦手なこと • パフォーマンス • ソースコードの記述量が多い • 局所的な開発スピードは遅い 01 なぜDDDで設計したのか

Slide 22

Slide 22 text

DDDが不向きなアプリケーションもある • 仕様が単純なシステム ex) 単純なCRUDだけのブログサイト • インフラが主役のシステム ex) 株の売買アプリケーション 01 なぜDDDで設計したのか

Slide 23

Slide 23 text

そしてDDDのメリット、デメリット比較の後 YappliはDDDを採用した

Slide 24

Slide 24 text

DDDΛ࠾༻ͨ͠΋ͷͷ՝୊͕࢒͍ͬͯͨ

Slide 25

Slide 25 text

02 軽量DDDになるという課題

Slide 26

Slide 26 text

軽量DDDとは • DDDの一部のみの考え方を取り入れたアプローチ • コンテキストの境界の定義を省略するパターンが多い • ドメイン知識のコード上での表現が達成できない 0 2 DDDで設計する上での課題軽量DDD = 技術的パターンのつまみ食い

Slide 27

Slide 27 text

軽量DDDあるある • entity, repository, useCase, serviceを作って満足する • ドメインエキスパートはいない • モデルはエンジニアの裁量で作る • コンテキストの境界が定義されていない • 集約の定義がなんとなくになる 0 2 DDDで設計する上での課題

Slide 28

Slide 28 text

ͳͥܰྔDDDͩͱμϝͳͷ͔?

Slide 29

Slide 29 text

軽量DDDの欠点最大の欠点は「知識をコード上で表現する」を実現できないこと = 複雑な仕様を表現できない = メンテナンス性の高いスケールするシステム設計ができない 0 2 DDDで設計する上での課題

Slide 30

Slide 30 text

軽量DDDの欠点最大の欠点は「知識をコード上で表現する」を実現できないこと = 複雑な仕様を表現できない = メンテナンス性の高いスケールするシステム設計ができない 0 2 DDDで設計する上での課題 →YappliͷߴػೳCMSͷෳࡶੑͷ௿ݮʹߩݙ͢ΔҰ൪ͷDDDͷ௕ॴ͕ੜ͔͖͠Εͳ͍

Slide 31

Slide 31 text

軽量DDDの欠点が露呈する例1: DB = entity ほぼDBモデル = entityになる現実世界に存在しない概念がentityとして存在。エンジニアだけでモデリングするとやりがち。ただ記述量が増えるだけ。 0 2 DDDで設計する上での課題 →ԾʹDBϞσϧ=entity͕࠷దͳΒ͹ɺDDD͸࠾༻͠ͳ͍ํ͕ྑ͍

Slide 32

Slide 32 text

軽量DDDの欠点が露呈する例2: 集約が歪む集約設計を怠り、後から集約の一部を扱うmethodがrepositoryに追加される (集約設計は戦術的DDDの話ではあるが、戦略的DDDを省略すると影響を受けやすい) 0 2 DDDで設計する上での課題 →υϝΠϯΤΩεύʔτͷߟ͑ͱζϨ࣮ͨ૷Λ͢Δͱ࢓༷௥Ճ࣌ʹ௧͍໨ʹ͋͏͜ͱ͕ଟ͍

Slide 33

Slide 33 text

Ͱ͸ɺͳͥܰྔDDDʹͳΔͷ͔?

Slide 34

Slide 34 text

03 軽量DDDになる要因

Slide 35

Slide 35 text

軽量DDDに陥る理由 • ドメインエキスパートとのコミュニケーションのコストが大きい • 答え合わせができないモデリングは体系化しにくい 03 軽量DDDになる要因

Slide 36

Slide 36 text

Slide 37

Slide 37 text

コミュニケーションコストがかかるドメインエキスパートとエンジニアは違う部署・チームにいることが多い。また、お互いに忙しい(スタートアップあるある)。実装時間を削るわけにはいかないので、結果的にドメイン知識を共有してモデリングする時間が失われるパターンはよくある。 03 軽量DDDになる要因

Slide 38

Slide 38 text

Slide 39

Slide 39 text

モデリングには答えがない • ドメイン知識は各プロダクト固有のもの • Yappliのモデリングの答えが世の中にあるわけではない • 体系化できない→だから戦略的DDDの本は少ない 03 軽量DDDになる要因

Slide 40

Slide 40 text

エンジニアの性質も・・・？技術指向の開発者は、自分の専門スキルを発揮できる、定量化可能な問題を楽しむものだ。ドメインに関する作業は面倒な上に、入り組んだ新しい知識を大量に必要とするが、そうした知識は開発者にとって、コンピュータ科学者としての能力を向上させるものではないように見えるのだ。(ドメイン駆動設計第1部より) →ΤϯδχΞ͸ఆྔԽͰ͖Δ໰୊=ମܥԽ͞ΕධՁՄೳͳ໰୊͕޷͖ →ٯʹɺυϝΠϯϞσϦϯάͷΑ͏ͳ౴͕͑ग़ͤͳ͍ →݁ՌɺઓུతDDD͸ஔ͖ڈΓʹ͞ΕɺܰྔDDDʹؕΔ 03 軽量DDDになる要因

Slide 41

Slide 41 text

Ͱ͸ɺͲ͏΍ͬͯ୤ܰྔDDD͢Δͷ͔?

Slide 42

Slide 42 text

04 脱軽量DDDのアプローチ

Slide 43

Slide 43 text

演繹的アプローチ vs 帰納的アプローチ • 演繹的アプローチ体系化された知識を当てはめて設計していく • 帰納的アプローチ事例をいくつか作って、後に知識を体系化していく 04 脱軽量DDDのアプローチ

Slide 44

Slide 44 text

演繹的アプローチ vs 帰納的アプローチ • 演繹的アプローチ体系化された知識を当てはめて設計していく • 帰納的アプローチ事例をいくつか作って、後に知識を体系化していく 04 脱軽量DDDのアプローチ →ؼೲతʹΞϓϩʔν͢Δͷ͕ྑͦ͞͏ɻίϛϡχέʔγϣϯɺϞσϦϯά౳ͷ౴͕͑ͳ͍໰୊ ʹରͯ͠͸ɺෳ਺ࣄྫ͔ΒYappliಠࣗͷମܥԽ͞Εͨ஌ࣝΛ࡞͍͚ͬͯ͹ྑ͍ͱ͍͏ൃ૝ɻ

Slide 45

Slide 45 text

ͭ·Γɺ·ͣ1ݸɺ୤DDDͷࣄྫΛ࡞Δ

Slide 46

Slide 46 text

05 PJの事例

Slide 47

Slide 47 text

PJの概要 CMS操作者の権限管理の仕組みを導入するPJ 0 5 PJの事例

Slide 48

Slide 48 text

作る機能の概要 ΧελϜϩʔϧͱ͍͏֓೦Λ࡞ΔɻΧελϜϩʔϧͰฤूͰ͖ΔػೳΛઃఆͰ͖Δɻ ֤ϝϯόʔʹΧελϜϩʔϧΛׂΓ౰ͯͯɺฤूͰ͖ΔείʔϓΛ੍ޚͰ͖Δɻ 0 5 PJの事例

Slide 49

Slide 49 text

PJ構成メンバーのイメージ • ディレクター • デザイナー2 人 • フロントエンジニア1 人 • サーバーサイドエンジニア3 人 • QAエンジニア、SREも関わる 0 5 PJの事例

Slide 50

Slide 50 text

06 実践モデリング

Slide 51

Slide 51 text

ユビキタス言語の定義 06 実践モデリング • PJチーム内で言葉の定義をした • 仕様策定と同時に行った • Figma上で議論した • 最終的には仕様書に落とされた

Slide 52

Slide 52 text

ユビキタス言語の定義 • PJチーム内で言葉の定義をした • 仕様策定と同時に行った • Figma上で議論した • 最終的には仕様書に落とされた υϝΠϯΤΩεύʔτ + ΤϯδχΞͰݴ༿Λἧ͑Δ͚ͩͰɺ ίϯςΩετͷڥք͸ܾ·Δɻ 06 実践モデリング

Slide 53

Slide 53 text

モデルの定義境界づけられたコンテキスト内にドメインモデルを定義する。【決まること】モデル名, 多重度, 大体のproperty名【決まらないこと】関連モデルの表現property 06 実践モデリング

Slide 54

Slide 54 text

集約を決める必要がある同じ集約で設計するパターン別集約で設計するパターン 06 実践モデリング

Slide 55

Slide 55 text

集約を正しく理解する集約の定義: transaction整合性をとりたいEntityのグループ集約の決め方は完全にシステム都合 (ドメインエキスパートは登場しない) VS どちらを選択するかはtransaction整合性をとれるかで判断するつまり集約を決めるためにDB設計をする必要がある 06 実践モデリング

Slide 56

Slide 56 text

集約を決めるためのDB設計登場したドメインモデルをもとにDB設計をする必要な情報をインフラ都合で最適化したDBモデルを作る 06 実践モデリング

Slide 57

Slide 57 text

集約を決める • memberとcustom_roleはそれぞれ別useCaseで独立して扱いたい • tabbarはメインDBと違うサーバで管理していてtransaction整合性は不可 06 実践モデリング

Slide 58

Slide 58 text

モデルの定義(再掲) コンテキスト内のドメインモデル【決まること】モデル名, 多重度, 大体のproperty名【決まらないこと】関連モデルの表現property 06 実践モデリング

Slide 59

Slide 59 text

モデルの定義(再掲) コンテキスト内のドメインモデル【決まること】モデル名, 多重度, 大体のproperty名【決まらないこと】関連モデルの表現property →集約が決まったのでもう決められる 06 実践モデリング

Slide 60

Slide 60 text

最終的なドメインモデル図コンテキスト内のドメインモデル【決まること】モデル名, property, 多重度, 集約 06 実践モデリング

Slide 61

Slide 61 text

͜͜·Ͱ͘Δͱentity, repository͸ ΋͏࣮૷Ͱ͖Δ!!

Slide 62

Slide 62 text

Entityのコード Entityを表すstructの定義とconstructorは実装でき 06 実践モデリング

Slide 63

Slide 63 text

Repositoryのコード 1集約に対して1repositoryが定義され 06 実践モデリング

Slide 64

Slide 64 text

͜ͷޙɺentityͷ֤ϝιουͱuseCaseΛ ࣮૷͍ͯ͘͜͠ͱʹͳΔ (ࠓճ͸লུ)

Slide 65

Slide 65 text

07 戦術的DDDの知見

Slide 66

Slide 66 text

ઓུతDDD͔Β࣮ફ͍ͯ͘͠ͱ ઓज़తͳ෦෼Ͱ΋஌ݟ͕ಘΒΕΔ

Slide 67

Slide 67 text

境界づけられたコンテキストの開発 07 戦術的DDDの知見 1個の境界づけられたコンテキストは • 1サブドメイン • 1マイクロサービス • 1 githubリポジトリ • 1開発チームで扱われることが多い。

Slide 68

Slide 68 text

モノリス × 複数サブドメイン一方でYappliではあらゆるサブドメインが一つのGoのソースコードで開発されている 07 戦術的DDDの知見

Slide 69

Slide 69 text

サブドメインをGoのpackageで表現する 1サブドメインを1packageで表現するこの辺りは言語仕様との相談になる DDD視点のサブドメインと言語仕様としてのpackageを混在させた点は妥協点 07 戦術的DDDの知見

Slide 70

Slide 70 text

他サブドメインとのやりとり例えばあるサブドメインから権限管理コンテキスト内のサブドメインに問い合わせる場合、オニオンの外側同士でやり取りはする。 07 戦術的DDDの知見

Slide 71

Slide 71 text

呼び出す側 07 戦術的DDDの知見まるで外部APIに問い合わせるかのように同github repositoryで定義されているhandlerにアクセスする他サブドメインとのやりとり

Slide 72

Slide 72 text

呼び出される側 07 戦術的DDDの知見アクセスされるhandlerにアクセスする他サブドメインとのやりとり

Slide 73

Slide 73 text

08 まとめ

Slide 74

Slide 74 text

まとめ • Yappliのドメイン知識は深く、DDDを採用した • 一方で、DDDの良いところを生かしきれていない課題もあった • まずPJ事例を作ることで脱軽量DDDを目指した • ユビキタス言語定義、ドメインモデリング、実装までの一連のフローを実現できた 08 まとめ

Slide 75

Slide 75 text

՝୊͸࢒͞Ε͍ͯΔ

Slide 76

Slide 76 text

課題に対してやりたいこと • 継続した脱軽量DDDの事例作り • 事例から得た本には書いていないYappli独自の知識の体系化 • サーバーチーム全体でのコーディングの統一化 • 継続的なリファクタリング 08 まとめ

Slide 77

Slide 77 text

՝୊͸͋Δ͕ɺղܾͰ͖Δ؀ڥ΋͋Δ

Slide 78

Slide 78 text

重要度: 高 , 緊急度: 低への意識重要だが緊急度が低いと着手されないことが多い。ヤプリの開発組織では左上領域を大切にする文化がある。 →結果的に戦略的DDDに真正面から取り組むことができた。 08 まとめ