LaravelにDDDを導入して1年経った所感(達成したこと / 課題点 / モデリングの難しさなど) - Qiita
背景 昨年公開したこちらの記事「Laravel でドメイン駆動設計(DDD)を実践し、Eloquent Model 依存の設計から脱却する」の続編です。 弊社で開発している「オンライン家庭教師マナリンク」の実装に DDD のアプローチを用いています。導入して 1 年が経過したので、いろいろと所感を述べていきます。 目次 どうして DDD を導入したか DDD で達成できたこと まだ難しいと思うこと 結局モデリングが一番難しい どうして DDD を導入したのか？ 導入した当初の動機は Laravel で Eloquent Model 中心に実装するアーキテクチャに嫌気が差したからです。 Eloquent Model 中心に実装するとあちこちにドメイン知識が散らばって、実装した自分ですらよくわからない、という状態によく陥りました。弊社はベンチャー企業で、トラフィックの多さを設計で考慮することは
ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが？ - Qiita
ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが？LaravelDDD設計アーキテクチャCleanArchitecture ある日夢の中で設計に詳しい悪役令嬢が現れてこんなことを言い放ったので、考察してみましたという設定のポエムです。 問題提起 ドメイン駆動設計、オニオンアーキテクチャ、クリーンアーキテクチャといった考え方はもちろん重要なものの、僕は難しく考えずに「削除しやすいように機能を作る」のが第一歩として重要ではないかと考えています。 本記事では「削除しやすい設計」について持論を展開してみます。 ※議論のスコープはWebサービスに限定し、例示としてPHPのフレームワークであるLaravelを用います 削除しやすいことがなぜ重要か 一度開発した機能は、それで終わりではなく、改修、改善を繰り返し、そして場合によっては仕様が廃止さ
Laravelでドメイン駆動設計(DDD)を実践し、Eloquent Model依存の設計から脱却する - Qiita
Laravelでドメイン駆動設計(DDD)を実践し、Eloquent Model依存の設計から脱却するPHPLaravelDDDドメイン駆動設計Eloquent この記事はドメイン駆動設計#1 Advent Calendar 2019の 10 日目の記事です。 2020/12/17追記 以下に続編を書きました！ LaravelにDDDを導入して1年経った所感(達成したこと / 課題点 / モデリングの難しさなど) やったこと 自社サイトのバックエンドを Laravel で実装して半年間が経ち、初期に考えた設計にいろいろと綻びが出てきたと感じていました。 そんな中、ちょうど実践ドメイン駆動設計や Web+DB Press で特集された体験 DDD を読むことができたので、さっそくいくつかの機能を DDD で実装してみました。 本記事では「もともと Laravel で実践していたEloquen
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
