Laravelでドメイン駆動設計(DDD)を実践し、Eloquent Model依存の設計から脱却する - Qiita
この記事はドメイン駆動設計#1 Advent Calendar 2019の 10 日目の記事です。 2020/12/17追記 以下に続編を書きました！ LaravelにDDDを導入して1年経った所感(達成したこと / 課題点 / モデリングの難しさなど) やったこと 自社サイトのバックエンドを Laravel で実装して半年間が経ち、初期に考えた設計にいろいろと綻びが出てきたと感じていました。 そんな中、ちょうど実践ドメイン駆動設計や Web+DB Press で特集された体験 DDD を読むことができたので、さっそくいくつかの機能を DDD で実装してみました。 本記事では「もともと Laravel で実践していたEloquent Model 依存の設計」の問題点を提起し、「DDD を取り入れて実装した結果」のソースコードや考え方、そのメリットを記載しています。 結論 Laravel の
Laravel で Service 層を取り入れるときに検討したいこと - Qiita
この記事について 普段何気なく使っている Service クラス（Service 層）について、書籍を中心にその役割や目的について書かれた資料を読みながら、Laravel 製のウェブアプリケーションに Service 層を取り入れる際の判断材料となるような情報や観点を、提供できればと思います。 以前にも調べたり考えたりしたんですが、そのときは明確な役割や使い方の提案ができなかったので、それの補遺的な位置づけになります。 Laravelでウェブアプリケーションをつくるときのベストプラクティスを探る (9) Service編 - Qiita Service レイヤーとは これ 出典: Martin Fowler's Bliki https://martinfowler.com/eaaCatalog/serviceLayer.html どんなときに Service 層が必要になるか Despit
Laravel5のアーキテクチャから学ぶより良いクラス設計 - Qiita
はじめに ウェブアプリケーションフレームワークのクラス構成にはさまざまなバリエーションがありますが、どれも様々なデザインパターンを駆使し、素晴らしいクラス構成になっています。 今回、じっくりフレームワークのソースコードを読むことで、少しでもいいクラス設計について学べるといいなぁと思い、このような企画を思いつきました。 PHP には様々なウェブアプリケーションフレームワークがあり、それぞれに特徴がありますが、今回は、近年突出して注目されている Laravel を取り上げます (いずれ他のフレームワークでも試してみたいです)。 環境 PHP 5.6.9 Laravel 5.2 やったこと Eloquent (Active Record) と DBファサード (Query Builder) の使い分け、ついでに Repository について Dependency Injection と Ser
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
