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

循環的複雑度80超えの現行システムに Laravel × オニオンアーキテクチャ で立ち向かっ...

循環的複雑度80超えの現行システムに Laravel × オニオンアーキテクチャ で立ち向かった話(栗原 史明 氏*株式会社うるる)

More Decks by 最新技術のエンジニア勉強会!シューマイ! ~Tech Lead Engineer~

Other Decks in Programming

Transcript

  1. 循環的複雑度 30 超えのシステムに Laravel × Onion Architecture で 立ち向かっ(た)ている話 2020/07/08

    【シューマイ】Tech Lead Engineerから最新技術を学べ!Laravel編 株式会社うるる NJSS事業部 プロダクト開発課 栗原 史明
  2. Agenda • はじめに • 自己紹介 • Onion Architecture って何? •

    Laravel x Onion Architecture • 具体例 • 実際やってみてどうだったか • まとめ
  3. • 今回お話すること ◦ オニオンアーキテクチャの重要となる部分の解説 ◦ Laravelで実装する場合の簡単な具体例 ◦ 実際に導入してみて改善・実感できたことと課題のお話 • 話さないこと

    ◦ Laravelの基本的機能の解説 ◦ オニオンアーキテクチャを使った詳細な実装のお話 ◦ オニオンアーキテクチャの詳細な解説 ◦ DDD(ドメイン駆動開発)の詳細なお話 はじめに
  4. 自己紹介 • 栗原 史明 • 株式会社うるる ◦ NJSS事業部 プロダクト開発課 •

    Laravel / Lumen • Docker / AWS / terraform / CDK • 認定スクラムマスター • あつ森で永遠と川を掘ってる
  5. Onion Architecture が実現したいこと • 重要なもの ◦ ビジネスロジック ▪ システム/プロダクトが目的とする処理を行うところ ▪

    例:売上計算のルール、日付の依存関係のルール など ◦ • 些細なもの ◦ フレームワーク、DB、テスト、インフラ、UI、ORM etc ◦ ※あくまでも「クリーンアーキテクチャ」の考え方で判断した場合
  6. Onion Architecture が実現したいこと • 重要なもの ◦ ビジネスロジック ▪ システム/プロダクトが目的とする処理を行うところ ▪

    例:売上計算のルール、日付の依存関係のルール など ◦ 変更が発生しにくい • 些細なもの ◦ フレームワーク、DB、テスト、インフラ、UI、ORM etc ◦ 簡単に変更できるもの/すべきもの ※あくまでも「クリーンアーキテクチャ」の考え方で判断した場合
  7. プロジェクト発足時に抱えてた思い (エンジニア目線) • メンテナンス性を上げたい ◦ Fat Controller / Fat Model

    で読みづらい ▪ メンテの度に4000行超えClass読むのしんどい ◦ テストが存在しない、というか循環的複雑度30超え当たり前 のメソッドにテスト書くなんて無理 • フレームワークであまり悩みたくない ◦ フレームワークは開発を補佐するものであり、設計を考える ことに時間を使いたかった
  8. Laravel x Onion Architecture • フレームワークの自由度が高く Onion Architecture の ディレクトリ構成を表現しやすい

    ◦ 基本的なMVCモデルではないディレクトリの切り方でも、 Laravelなら対応できる ▪ 自分たちの特性に合わせたディレクトリ構成を組みやすい ◦ やっぱり何かと便利なEloquent ◦ 足りない機能をComposerで補う動きもやりやすい
  9. Laravel x Onion Architecture • Onion Architecture に必須なDIをデフォルトでサポート ◦ Interface

    から実体Classを呼ぶための機能 ◦ Providerに対して app->bind() で設定することができる
  10. Laravel x Onion Architecture • トラブルシューティングがしやすい ◦ 公式DocやQiitaなど日本語のドキュメントが豊富 ◦ Laravel起因のエラーは大体誰かが経験している

    ▪ ggrな状況になっても割とどうにかなる ◦ 挑戦的なアーキテクチャの導入は最初は迷いやすいので、フ レームワーク起因のトラブルが対処しやすいのは迷うポイン トを減らす観点で大きなメリット
  11. 具体例 • こういう要件があったとする ◦ ユーザ情報を保存するAPIを作りたい ◦ 保存する内容は 名前 / ニックネーム

    / メアド ◦ ユーザ識別詞としてメアドをsha256でハッシュ化する ※「こんな要件本当に存在するのか?」  という質問については一例なので気にしたら負けです。
  12. プロジェクト発足時に抱えてた思い (エンジニア目線) • メンテナンス性を上げたい ◦ Fat Controller / Fat Model

    で読みづらい ▪ メンテの度に4000行超えClass読むのしんどい ◦ テストが存在しない、というか循環的複雑度30超え当たり前 のメソッドにテスト書くなんて無理 • フレームワークであまり悩みたくない ◦ フレームワークは開発を補佐するものであり、設計を考える ことに時間を使いたかった
  13. プロジェクト発足時に抱えてた思い (エンジニア目線) • メンテナンス性を上げたい ◦ Fat Controller / Fat Model

    で読みづらい ▪ メンテの度に4000行超えClass読むのしんどい ◦ テストが存在しない、というか循環的複雑度30超え当たり前 のメソッドにテスト書くなんて無理 • フレームワークであまり悩みたくない ◦ フレームワークは開発を補佐するものであり、設計を考える ことに時間を使いたかった Onion Architecture の導入で改善!! Laravel の導入で実現!!
  14. • とにかく設計に悩んだ。悩んでる。(※現在進行形) ◦ 慣れてないうちはどこの層に書けば良いのか悩んだ ◦ 慣れてくると今度はどこまで責務分割させるか悩んだ、今も 悩んでる ▪ 完璧に拘り過ぎるとClassの分割が多すぎてしんどい ▪

    単純な実装の場合は却って複雑さを招く場合も ▪ 私のチームでもインフラ依存の完全な分割はやりきれてないですし、敢えて割り 切っている部分もあります とはいえ課題もあります
  15. Onion Architecture が実現したいこと • 重要なもの ◦ ビジネスロジック ▪ システム/プロダクトが目的とする処理を行うところ ▪

    例:売上計算のルール、日付の依存関係のルール など ◦ 変更が発生しにくい • 些細なもの ◦ フレームワーク、DB、テスト、インフラ、UI、ORM etc ◦ 簡単に変更できるもの/すべきもの ※あくまでも「クリーンアーキテクチャ」の考え方で判断した場合
  16. プロジェクト発足時に抱えてた思い (エンジニア目線) • メンテナンス性を上げたい ◦ Fat Controller / Fat Model

    で読みづらい ▪ メンテの度に4000行超えClass読むのしんどい ◦ テストが存在しない、というか循環的複雑度30超え当たり前 のメソッドにテスト書くなんて無理 • フレームワークであまり悩みたくない ◦ フレームワークは開発を補佐するものであり、設計を考える ことに時間を使いたかった Onion Architecture の導入で改善!! Laravel の導入で実現!!
  17. 補足 • PHP7.4 が使えるなら PHP7.4 以上を推奨 ◦ プロパティ変数に型定義ができるので、型推論によりClassで 表現できる内容がより強化される •

    本日会話した内容は Lumen でも(ほぼ)そのまま実現可能 ◦ 「Laravel側はAPIのみ」等の条件が揃えば Lumen でも実現可 能。速度要件があるなら一考の余地アリ ◦ ただし、Laravel 拡張が使えないパターンがあるので、不安で あれば Laravel を選んでおくと間違いはない