株式会社ラクスのrakusMoritaです。
2021年2月22日にオンラインで開催された Laravel Meetup Tokyo Vol.13 に参加したので、内容のポイントをまとめてみました。
どの話も興味深く、そして実践しやすい内容だったので共有させていただきます。
laravel-meetup-tokyo.connpass.com
Laravelと継続的デプロイ
スピードと質を求められている状況下での基本構成
クラウド
・コスト削減
・スケーラビリティが容易
コンテナ
・作業時間短縮
・DevOpsとの相性良い
注意点等
ログの構造化は必須
AWSのCloudWatch等で、ログは構造化（JSON化）しておくとのこと。
視認性が格段にアップして開発やデバッグ・調査の時短になる。vendor内をコンテナ化していると、ビルドに時間がかかったりする場合がある
安定性は向上するので、どちらを取るかは組織内で要相談。デプロイを自動化していたとしても、突然デプロイが失敗することもある
デプロイが短時間でできると思っていても、デプロイ当日にパニックになることもあるので、余裕を持ったスケジュール組むこと。
そして、定期的なデプロイをして、突然の「動かない」を極力なくす。
継続的なデリバリのために組織として取り組むこと
- 運用できる人を増やす
一部の人しか触れないではなく、なるべく多くの人が携わる。
関係者を巻き込みながら、少しずつやれることを増やしていく
体制面でも継続可能な状況を作ることが理想。
ログの構造化は確かに必須ですね。個人的に即効性があって良いと思いました。
DDD入門とLaravel
最近よく耳にする「ドメイン駆動設計」、通称「DDD（domain-driven design）」ですが、具体的にわかりにくいと思いませんか？
今回具体的にどういうことなのかを掘り下げた内容が聞けて勉強になりました。
DDDの理解でよくある間違い
「アーキテクチャで、層に分かれて実装すれば良い」 これ、間違いです
「 DDDでデータベース肥大化対策どうやるの？」 実は関係ありません
「MVCではDDDはできないのでは？」 これも全く関係ありません
「DDDで実装したけど、全然楽になりません」 長期的に見ると楽になるはず・・・
結局DDDって何？
開発スタイルのひとつ
「実現したいこと」や「解決したい問題」、それを「ドメイン」という。
その「やりたいこと」を起点として開発していくのがDDD。実装言語やフレームワーク、ストレージやアーキテクチャなどは含まれない 一般的な非機能要件は含まれない。
機能要件が含まれる。
DDDは、どういうアーキテクチャで、どういう言語、フレームワーク、データベース・・・などの技術的な要素とは一切関係なく、何を作るのか？それを考えて実現していくことだったのですね。
一般的な「ドメイン」と違うのが理解し難くしている原因の一つかもしれません。
DDDのメリット
何をしたいかをまず考えるため、先を見越した設計ができる
開発チームで共通の認識が生まれ、認識のずれからくるやり直しや確認が減る
突然の仕様変更に困ったことはありませんか？システムや機能の根幹を揺るがしかねない事態になる可能性だって往々にしてあります。
そういう事態を未然に防ぎやすいのがDDDの特徴です。
「何を実現したいか」が関係者で共有ができているため、設計段階から将来の変更を見越したものが作りやすいというわけです。
膨大な改修コストや、目的からずれた不要な機能開発とはこれでおさらばです。
どうやって実践するの？
カスタマーサービスチームに加わったり企画会議に参加して、開発以外の概念理解や知識をつける
ユーザー層や実現したいこと、チーム構成は変わっていくため、継続的にコミュニケーションや分析を行う
チーム全員でドメイン（会社が提供したい価値）モデルを導き出し、全員で同じ認識と同じ言語で共通理解をする
言葉の認識を合わせていくことが大切とのこと。
例えば「ユーザー」という言葉でも、エンジニアは「DBのユーザーテーブルのことだな」と思っていても、実際は「会員」を指しているのかもしれないし、「有料会員」のことを指すのかもしれない。
まずはその共通認識を行うことが第一歩。
文脈でもその意味は変わってくるので、そのバックグラウンドに基づく知識が共有できていれば、迷いやすれ違いが少なくなるとのこと。
よく聞く軽量DDDとはどう違うの？
軽量DDDとは、DDDで得られた知識を反映しやすい実装パターン、構造だけを採用したもので、DDDとは別物です。
こちらの意味だけが先行して、DDDの本質を見失う人も多そうな印象ですね。
実装するには
Laravel等を用いて開発するときは、DDDの知識を落とし込みやすいパターンを無理に最初から実現しなくても良い
処理の共通化を行わず、まずは分析と知識に基づいて、クラスにする
同じような箇所はコピペでも良い。あとから共通化させるほうが収束しやすいし、リファクタリングもしやすい。
まずは本当に共通化すべきもののみ共通化すること。
余談ですが、「設計をちゃんと考えるようになってからコピペが増えた」なんて話もちらほら聞きます。
DDDは詳しく知らなかったので、聞きながら実践イメージもわき、非常に興味深かったです。
Laravel8で使えるJavaScriptパッケージ「Inertia.js」が便利
Laravel8で使える、ビューとのデータのやり取りが容易になるJavaScriptパッケージ「Inertia.js」でお手軽にモダンなSPAが構築できるというお話もありました。
軽く紹介があったので、調べて簡単にまとめてみました。
Inertia.jsとはLaravel8の標準認証ライブラリ「Jetstream」で使われている、フロントエンドとバックエンドのデータ連携技術
Vueファイルとのデータ連携がテンプレートエンジンと同じように扱えるため、SPA化も容易
Vue.jsなどでSPAを実現するには、Ajaxの制御やVue側でルーティングを行う必要があり、開発コストがかさみやすいですが、それが不要になります。
Laravelのルーティングの記述で、Ajax通信・ルーティングも一緒にコントロールできるので楽にSPAを実現できるのが魅力的ですね。
TDD視点から見るRequestクラスの依存性
- Requestクラスにはユーザー認証や情報の保持、バリデーションなど、色々な情報がありすぎて、ユニットテストが書きづらい
バリデーションと認証が共存しているなど、テストクラスの文脈がぶれることがあるので、何をしているテストかわからない。何をテストすればいいかわかりにくいという内容で、そこから転じて
「なんでもやってるクラスはテストがつらい。」
この心の叫び、エンジニアあるあるではないでしょうか？
設計や実装時にはそう思われないクラスづくりが大切だと改めて考えさせられました。
まとめ
色々気づきや発見のある有意義な時間でした。
個人的にはDDDの概念が理解できたことが大きな収穫でした。
ドメイン駆動はいわば「本質を見失わない開発」ということだったのですね。
また参加してみたいと思います。
