Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
スタートアップでシードからシリーズAのLaravelでどうアーキテクチャを変化させたのか?
Search
スー
May 22, 2024
0
250
スタートアップでシードからシリーズAのLaravelでどうアーキテクチャを変化させたのか?
# アーキテクチャを考える上でのまとめ
1. 事業が増えると情報整理が急務になる
2. コンウェイの法則から逃れられない
3. オンボーディングの体験を上げるための工夫が必要
スー
May 22, 2024
Tweet
Share
More Decks by スー
See All by スー
PHPの型システムが言ってることがわからない
suguru_ohki
1
130
生成AIを使ったコーディング
suguru_ohki
0
88
認知負荷を下げるオンボーディング体験
suguru_ohki
0
170
スタートアップでDDDを始めた時の困難
suguru_ohki
0
160
Featured
See All Featured
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Code Reviewing Like a Champion
maltzj
519
39k
For a Future-Friendly Web
brad_frost
175
9.4k
GitHub's CSS Performance
jonrohan
1030
460k
Raft: Consensus for Rubyists
vanstee
136
6.6k
A Philosophy of Restraint
colly
203
16k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
228
52k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Measuring & Analyzing Core Web Vitals
bluesmoon
2
53
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Transcript
スタートアップでシードからシリーズA のLaravel でど うアーキテクチャを変化させたのか?
シリーズA に向けて事業が1 つから3 つに増えたスタートアップが、Laravel の レイヤードアーキテクチャから戦術的DDD への移行をどのように実現したかを 紹介します。 2024-03-29 |
スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 2
自己紹介
所属 株式会社TechBowl 住んでるところ 東京 何やってる? 「TechTrain 」というサービスで反復横跳びし続けている 何でも屋さん(Laravel, Next.js, AWS,
etc...) 趣味 お酒( よく溺れる) サウナ 読書 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 4
TechTrain エンジニア教育+Direct スカウトのサービス。 Coding Stoic をテーマにちゃんとコードを書いていこう ね!というメンターが多めのエンジニアを育てるための サービスです。 2024-03-29 |
スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 5
一緒に働いてくれる人を探しています! 1. バックエンドエンジニア(Laravel + DDD) 2. フロントエンドエンジニア(Next.js with TypeScript) 3.
TechTrain のメンター -> 筋がいい人なら教えたいぜ! 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 6
2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 7
アジェンダ 1. 事業背景と課題 2. アーキテクチャをどう変えたのか? 3. そのほかにやったこと 2024-03-29 | スタートアップでシードからシリーズA
のLaravel でどうアーキテクチャを変化させたのか? 8
1. 事業背景と課題 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 9
1. 事業背景と課題 シード 事業は1 つ 売り上げも大事だが、ニーズがあるのかの検証が大事なフェーズ ほぼLaravel に従ったざっくりレイヤーを分けたアーキテクチャ シリーズA 事業が1
つから3 つほどに増加 ニーズに幅が出始め、どのニーズにどのように提供していくかが問題になり 始める レイヤーだけだと情報が整理しきれなくなってくる 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 10
2. アーキテクチャをどう変えたのか? 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 11
Before ├── app │ ├── Console │ ├── Exceptions │
├── Facades │ ├── Helpers │ ├── Http │ ├── Mail │ ├── Models │ ├── Notifications │ ├── Observers │ ├── Providers │ ├── Rules ↑ ここから上は、Laravel のデフォルトディレクトリ │ ├── Repositories <-- ゆるふわリポジトリ │ ├── Services <-- ドメインサービス │ └── UseCase <-- ユースケース 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 12
After ├── app <--- ここはディレクトリ構成はほぼ変わらず。以前のRepository~Usecase をDeprecated へ。 ├── Package <---
追加 │ ├── Adapter │ ├── Application │ ├── Domain │ └── Infrastructure 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 13
何を主眼としたのか? 2-1. どこに何の事業のロジックがあるのかわかるようにする 2-2. 現在のディレクトリに無理やり手を入れなくても良い 2-3. 人数を無理やり増やさなくても良いようにする 2024-03-29 | スタートアップでシードからシリーズA
のLaravel でどうアーキテクチャを変化させたのか? 14
2-1. どこに何の事業のロジックがあるのかわかるようにする 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 15
Before app ディレクトリのService クラスによく複数のドメインの情報が混入していた。 <?php namespace App\Services; class MeetingService {
public function createMeeting() // <- 実は特定のユーザー属性からしか呼ばれてはならない { // 面談の作成処理 return $created_meeting->toArray(); // 一体中身どの属性を持ってるんだ・・・( 震え声) } public function updateMeeting() // <- 実はどのユーザー属性からも呼ばれてしまう { // 面談の更新処理 return $updated_meeting->toArray(); // 一体中身どの属性を持ってるんだ・・・( 震え声) } } 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 16
ある意味ドメイン情報の分割がうまくいってなかったが、層としての分割としてはあ る程度機能していたため、このような問題が発生。 認知負荷が上がる原因となっていた 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 17
After どの事業ドメインで誰が何を行うのか?といった分割を行った 更新だけ取り出して説明 <?php namespace Package\Application\TechTrain\User\Meeting\Update; // 誰が行うのか?をnamespace で表現 final
class MeetingUpdateUsecase { public function exec(MeetingUpdateInput $input): MeetingUpdateOutput // DTO を利用して入出力を明確化 { // 面談の更新処理 } } User 以外が更新を行う場合は namespace Package\Application\TechTrain\[ 別のユー ザー属性]\Meeting\Update\MeetingUpdateUsecase を追加 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 18
2-2. 現在のディレクトリに無理やり手を入れなくても良い 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 19
前提としてPHP のプロジェクトであるため、次のようなミスをしてはならない 1. ネームスペースとディレクトリ構成が一致していない 2. 大文字小文字の区別が甘い 2024-03-29 | スタートアップでシードからシリーズA のLaravel
でどうアーキテクチャを変化させたのか? 20
1. ディレクトリ変更を大きくしない方がミスは防げそう 2. 人数もそんなに多くなく、インターン生がミスをしないようにした方が良い 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 21
手段に対して必要な条件 1. ディレクトリの追加のみでロジック実装が可能 2. 既存のLaravel のartisan コマンドを拡張し、生成 3. ミスが起きづらい仕組みを作成 2024-03-29
| スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 22
手段に対して必要な条件 1. ディレクトリの追加のみでロジック実装が可能 app ディレクトリ外に新しくディレクトリを作成 2. 既存のLaravel のartisan コマンドを拡張し、生成 app
ディレクトリの構成を大きく変えない 3. ミスが起きづらい仕組みを作成 生成コマンドを作り、カバーする 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 23
After ├── app <--- ここはディレクトリ構成はほぼ変わらず ├── Package <--- 追加 │
├── Adapter │ ├── Application │ ├── Domain │ └── Infrastructure 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 24
After: 生成コマンド 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 25
2-3. 人数を無理やり増やさなくても良いようにする 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 26
アーキテクチャ => 「コンウェイの法則」からは逃れられない 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 27
当時のエンジニア組織の体制 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 28
事業を複数またがることから情報整理が急務 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 29
情報整理+ 機能実装を的確に実装したい 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 30
戦略的DDD の考え方が望ましいと判断 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 31
ざっくりアーキテクチャの選択肢 マイクロサービスにする モノリスにする 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 32
マイクロサービスで戦術的DDD を実現するには、事業が3 つあるので、少なくとも 数ヶ月でリードクラスを3 名以上取る必要がある 入ってから活躍していただくまで大体6 ヶ月くらいかかる マイクロサービスにすると1 人1 つのサービス担当という形式になることが想定さ
れ、内部の実装の共有が難しくなりかねない マイクロサービスの経験者が当時の候補者にいなかった 戦術的DDD はモノリス内で実装するといった方針が良さそうと判断し、アーキテ クトでモノリスで実装した経験がある方を採用 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 33
戦術的DDD を実現する アーキテクトの採用が急務となった 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 34
無事採用できたため、次の体制で移行を推進していった アーキテクト アーキテクトが考えたことを実装するドライバー 機能実装を行う今まで所属していたメンバー 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 35
3. そのほかやったこと 3-1. アーキテクト図を用意 3-2. オンボーディング資料の充実 3-3. ドメインモデル図を用意 2024-03-29 |
スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 36
3-1. アーキテクト図を用意 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 37
3-2. オンボーディング資料の充実 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 38
3-3. ドメインモデル図を用意 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 39
3-3. ドメインモデル図を用意 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 40
アーキテクチャを考える上でのまとめ 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 41
アーキテクチャを考える上でのまとめ 1. 事業が増えると情報整理が急務になる 2. コンウェイの法則から逃れられない 3. オンボーディングの体験を上げるための工夫が必要 2024-03-29 | スタートアップでシードからシリーズA
のLaravel でどうアーキテクチャを変化させたのか? 42
Personal Open Code! 実装の詳細を実際に見ながらやアーキテクチャについて議論した い! @suguru_ohki にDM かメッセくださいませ! 一緒に話してより良いアーキテクチャになるように議論したいです! 2024-03-29
| スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 43
ご清聴ありがとうございました! 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 44
2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 45