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に依存
密結合は良くない
- デプロイのしづらさ
- レンダリングの責務肥大
- 切り離しづらい
失敗の結論
-
０−１に向かう中そのままシステムを拡張した。
-
個人から複数人での開発を配慮しなかった。
フルリニューアル中…
アーキテクチャをチームで検討
どこで何をやるのか
責務・構成などを検討
Facadeはユーティリティ的な
使い方のみ
DI機能でControllerを薄く
-
どこまで薄くするか…
-
プレゼンターどうする？ Entity？Controller？
サービス層の導入
ドメインとアプリケーションのサービスを分けて考える
インフラ層
例）SMSの通知やメール配信、外部サービスを利用する
ものを分ける
- 送信命令はアプリケーション層
- 構築（連結）部分はドメイン層
- 配信はインフラ層
例）複数の明細PDFを連結しまとめてメール送信したい。
複数APPのAPI一本化
０⇛１で学んだこと
０で大事なこと
とにかくPMF
MVPの繰り返し
（Minimum Viable Product）
奇麗に作りすぎない
失敗を繰り返す
How より Why
サービス思考
１で大事なこと
立ち止まる勇気と交渉
How より Why
サービス思考
プロダクト思考
Why？
開発をして何をしたいのか
-
良いシステムを作る
-
良いサービスを作る
-
不確実性に対処する
エンジニア仲間を募集しています。
-
1-10の成長を体験したい
-
サービスづくりの実感が欲しい
-
可能性のある事業にコミットしたい
SaaS伸びてますよ！