DDDとCQRSについて DDD (Domain Driven Design = ドメイン駆動設計)が世間に知られるようになってきましたが、今度はDDDをさらにスケーラビリティにするCQRS (Command Query Responsibility Segregation = コマンドクエリ責務分離)が出てきました。 DDD提唱者の英語本の和訳版「エリック・エヴァンスのドメイン駆動設計」がAmazonにありますが、非常に分厚く高価です。概要をまとめた資料が「Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 - InfoQ」から入手できます。 CQRSはデータベース設計とイベントソーシングも含めた壮大なWebアプリケーションのアーキテクチャですが、日本語の資料がまだ少ないです。CQRSを適用したアプリケーションを構築できるインフラがWindows Az
きっかけは、「オブジェクトからサービスへ」というエントリに対して、通りがかりさんからコメントいただいたことだった。これまで、長い間、もやもやしたものを感じていたのだ。 オブジェクト指向の本を紐解くと、データと振る舞いをクラスにカプセル化すると書かれている。僕も疑問は、そもそも、それが正しいのか、つまり、データに振る舞いを持たせる必要性があるのだろうか？賢いデータは必要なのか？ということだ。 Javaでは、データと振る舞いの分離が進んでいる まず、現状として、Javaの世界では、データと振る舞いの分離が大きくすすんでいる。EJBにしても、EntityBeanとSessionBeanというのは、データと振る舞いの関係にあり、分割がよいこととされている。さらに、O/Rマッピングツールが流行するにつれ、データの保持クラスはPOJOとなった。一方、ビジネスロジックは、FacadeやServiceと
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く