Laravel  

0⇛1創業の失敗と学んだ事

株式会社タノム

福岡 一樹

2019/08/07 【シューマイ】Tech Lead Engineerから最新技術を学べ!Laravel編

 

福岡 一樹  Fukuoka Kazuki

1983年、千葉県出身

 

専門学校卒業後、ネットプライス⇛デファクトスタンダードでブランディア立ち上げに参画⇛現在はタノムCTO

 

バックエンド、フロント、インフラなど

広く浅いフルスタック

受発注をスマホでカンタンに

画像

UI

受注業務の効率化、販促支援を実現する

飲食卸のB2B SaaS

技術スタック

今回、技術的な話は

ほとんどしません

本題

Laravelの良い所

柔軟性

拡張性

良い所は悪い所

Simple ≠ Easy

具体的な失敗例

・Facadeの多用

・モノリシックな構成

・アーキテクチャの理解不足

Facadeの多用

・テストしやすい

・共通メソッドがどこでも呼べるから便利!

はじめは・・・

  • ロジックが複雑化

  • 責務が不明瞭

  • タイプヒントされない

簡単にスパゲッティコード

Facade警察に逮捕

アーキテクチャの理解不足

@Contoller

  • ビジネスロジック
  • DBアクセス
  • レスポンスのフォーマット

@Job, @Notification, @Event

@Blade

やりがちな失敗

@Service

責務がバラバラで

改修・改善に伴う

影響範囲の拡大

モノリシックな構成

  • Bladeの使用
  • Laravel on Vuejs

Blade

社内管理

取引先

Laravelに依存

密結合は良くない

  • デプロイのしづらさ
  • レンダリングの責務肥大
  • 切り離しづらい

失敗の結論

  • 1に向かう中そのままシステムを拡張した。

  • 個人から複数人での開発を配慮しなかった。

フルリニューアル中…

アーキテクチャをチームで検討

どこで何をやるのか

責務・構成などを検討

Facadeはユーティリティ的な

使い方のみ

DI機能でControllerを薄く

  • どこまで薄くするか…

  • プレゼンターどうする? Entity?Controller?

サービス層の導入

ドメインとアプリケーションのサービスを分けて考える

インフラ層

例)SMSの通知やメール配信、外部サービスを利用する

  ものを分ける

  • 送信命令はアプリケーション層
  • 構築(連結)部分はドメイン層
  • 配信はインフラ層

例)複数の明細PDFを連結しまとめてメール送信したい。

複数APPのAPI一本化

0⇛1で学んだこと

0で大事なこと

とにかくPMF

MVPの繰り返し

Minimum Viable Product

奇麗に作りすぎない

失敗を繰り返す

How より Why

サービス思考

1で大事なこと

立ち止まる勇気と交渉

How より Why

サービス思考

プロダクト思考

Why?

開発をして何をしたいのか

  • 良いシステムを作る

  • 良いサービスを作る

  • 不確実性に対処する

エンジニア仲間を募集しています。

  • 1-10の成長を体験したい

  • サービスづくりの実感が欲しい

  • 可能性のある事業にコミットしたい

SaaS伸びてますよ!