【Laravel】【DDD】ちょっと待って！そのEloquent、本当にドメインモデルにしちゃって大丈夫？ - Qiita
【Laravel】【DDD】ちょっと待って！そのEloquent、本当にドメインモデルにしちゃって大丈夫？LaravelDDDドメイン駆動 お題目 Eloquentはとっても便利！ あまりにも便利なのでEloquentをそのままドメインモデルにしたくなっちゃう！ でも、何も考えずにドメインモデル化すると酷い目に合うかも…？ なんで？ 何がいけないの？ Eloquentが扱う問題領域（DB操作）は本来インフラストラクチャ層が正解。 つまり、Eloquentをドメインモデルとして扱ってしまうと、レイヤー構造（≒責務の範囲）の侵犯による副作用が発生する。 つまり…どういうことだってばよ？ 1.他層のDB操作に歯止めが掛からなくなる ドメインクラスを経由すればどこでもDBを弄れるので、最悪だと「アプリケーション層からInsertを書く」なんて芸当が可能。 「ヘボグラマーが各種バリデーションやエラー
混乱しがちなサービスという概念について - かとじゅんの技術日誌
社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま
RDRA DDD Agile
11. サービスの会社が 業務システムに取り組む話 • アソビュー • 全国のレジャー・遊び・体験が探せる日本最大 級の検索・予約サイト • バックオフィス業務は必要最小限、かつ人間系 でがんばっているが… • 事業のさらなら発展のためには • バックオフィスのシステム充実が必須 • ただし、 • ビジネスモデルや業務フローは変わり続ける 12. 電子チケットサービス • ネット上で電子チケットの購入 • 入場時に、電子チケットの提示と「もぎり」 • 挑戦 – 金流の変更 • before : 主催会社にお金が入り、手数料を請求 • after: アソビューにお金が入り、主催会社に支払い – バックオフィス業務の複雑化 – 確実性や迅速性の要求 – バックオフィスシステムの開発経験不足
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - j5ik2o/spetstore: Scala+DDDのサンプルとしての実装
Developers Summit 2014 「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」
InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版