Upgrade to Pro — share decks privately, control downloads, hide ads and more …

スタートアップでシードからシリーズAのLaravelでどうアーキテクチャを変化させたのか?

スー
May 22, 2024
250

 スタートアップでシードからシリーズAのLaravelでどうアーキテクチャを変化させたのか?

# アーキテクチャを考える上でのまとめ

1. 事業が増えると情報整理が急務になる
2. コンウェイの法則から逃れられない
3. オンボーディングの体験を上げるための工夫が必要

スー

May 22, 2024
Tweet

Transcript

  1. 所属 株式会社TechBowl 住んでるところ 東京 何やってる? 「TechTrain 」というサービスで反復横跳びし続けている 何でも屋さん(Laravel, Next.js, AWS,

    etc...) 趣味 お酒( よく溺れる) サウナ 読書 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 4
  2. 一緒に働いてくれる人を探しています! 1. バックエンドエンジニア(Laravel + DDD) 2. フロントエンドエンジニア(Next.js with TypeScript) 3.

    TechTrain のメンター -> 筋がいい人なら教えたいぜ! 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 6
  3. 1. 事業背景と課題 シード 事業は1 つ 売り上げも大事だが、ニーズがあるのかの検証が大事なフェーズ ほぼLaravel に従ったざっくりレイヤーを分けたアーキテクチャ シリーズA 事業が1

    つから3 つほどに増加 ニーズに幅が出始め、どのニーズにどのように提供していくかが問題になり 始める レイヤーだけだと情報が整理しきれなくなってくる 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 10
  4. Before ├── app │ ├── Console │ ├── Exceptions │

    ├── Facades │ ├── Helpers │ ├── Http │ ├── Mail │ ├── Models │ ├── Notifications │ ├── Observers │ ├── Providers │ ├── Rules ↑ ここから上は、Laravel のデフォルトディレクトリ │ ├── Repositories <-- ゆるふわリポジトリ │ ├── Services <-- ドメインサービス │ └── UseCase <-- ユースケース 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 12
  5. After ├── app <--- ここはディレクトリ構成はほぼ変わらず。以前のRepository~Usecase をDeprecated へ。 ├── Package <---

    追加 │ ├── Adapter │ ├── Application │ ├── Domain │ └── Infrastructure 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 13
  6. 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
  7. 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
  8. 手段に対して必要な条件 1. ディレクトリの追加のみでロジック実装が可能 app ディレクトリ外に新しくディレクトリを作成 2. 既存のLaravel のartisan コマンドを拡張し、生成 app

    ディレクトリの構成を大きく変えない 3. ミスが起きづらい仕組みを作成 生成コマンドを作り、カバーする 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 23
  9. After ├── app <--- ここはディレクトリ構成はほぼ変わらず ├── Package <--- 追加 │

    ├── Adapter │ ├── Application │ ├── Domain │ └── Infrastructure 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 24
  10. マイクロサービスで戦術的DDD を実現するには、事業が3 つあるので、少なくとも 数ヶ月でリードクラスを3 名以上取る必要がある 入ってから活躍していただくまで大体6 ヶ月くらいかかる マイクロサービスにすると1 人1 つのサービス担当という形式になることが想定さ

    れ、内部の実装の共有が難しくなりかねない マイクロサービスの経験者が当時の候補者にいなかった 戦術的DDD はモノリス内で実装するといった方針が良さそうと判断し、アーキテ クトでモノリスで実装した経験がある方を採用 2024-03-29 | スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 33
  11. 3. そのほかやったこと 3-1. アーキテクト図を用意 3-2. オンボーディング資料の充実 3-3. ドメインモデル図を用意 2024-03-29 |

    スタートアップでシードからシリーズA のLaravel でどうアーキテクチャを変化させたのか? 36