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 で Request, UseCase, Resource を使いコントロールフローをシンプルにする - Qiita
この記事について 「Clean Architecture」（Robert C. Martin 著）に触発されて、ユースケースパターンを試してみたので、その記録です。 本書では UseCaseInteractor という名前になっていますが、本記事のサンプルでは UseCase としています。 あくまでも触発されただけなので、Clean Architecture に完全に沿ってるわけではないので、その点だけご注意ください、詳しくは書籍をお読みいただければ、と思います。 環境 PHP: 7.1.16 Laravel: 5.5.42 サンプルコード 「Clearn Architecture」にある Interactor についての記述を引用します。 ウェブサーバーは、ユーザーからの入力データを受け取り、左上のControllerに渡す。ControllerはプレインオールドなJavaオブジェクト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Inside pixiv's infrastructure〜application cluster side〜
