Implementing Domain-Driven Design: Part 1
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ
DDDで設計するならCQRSの利用を検討すべき - Qiita
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
「開発しない」という越境 #DevLOVE - assertInstanceOf('Engineer', $a_suenami)
このエントリは DevLOVE Advent Calendar 2014 「越境」 の5日目です。 つい先日申し込んだのに予想外に早くバトンがまわってきました。笑 前日は @azumi さんの「【マンガ】旅行サービス開発のデザイン現場へ。種を持ち帰る『越境』の旅」でした。まさかマンガとは！笑（楽しく読ませていただきました。） @azumi さんは産業技術科学大学の人間中心設計プログラムにいらっしゃるのですね。弊社の社員も現在通っていて、一緒に学んでいるようです。 さて、僕は昨年に引き続き今年も DevLOVE Advent Calendar に参加させていただきます。 昨年のエントリはこちら。 現場の反対はまた別の現場 #DevLOVE - assertInstanceOf('Engineer', $a_suenami) 自己紹介 すえなみと申します。漢字で書くと末並です。「末波」とよく間
DevLOVE Beautiful Development - 第一幕 陽の巻
This document provides an overview of domain-driven design (DDD) patterns and principles including: 1. It discusses common DDD patterns such as entities, value objects, aggregates, factories, repositories and services. 2. It explains the differences between entities and value objects and how they are used in a domain model. 3. It covers key DDD concepts like modeling the domain, isolating the doma
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
