Cloud時代のArchitecture - LunaBiblos
概要 TechEd2010 T1-502「クラウド コンピューティングの最先端技術動向と選択の戦略」に参加した後のメモと整理です。 CQRSモデル MVC(Model、View、Controller)との決別 CQRSとは あらゆるMethodはActionを実行するCommandか、呼び出し元にDataを返すQueryの何れかであり、両方を行ってはならない。 CQRSは「Command Query Responsibility Segregation」の略語である。日本語で言えば「コマンドクエリ責務分離」。もっと解りやすく言えば「更新処理と参照処理とに対する応答部分を明確に分離する」事である。 構造としてSystemを次の四つに分類する。 Query(参照) Command(更新) 内部Event 外部Event(公開Event) MVCの終わり CQRSの観点から見ると多くの
Greg Young流CQRS - Mark Nijhof - Digital Romanticism
この記事はMark Nijhof氏のブログ記事「CQRS à la Greg Young」を氏の許可を得て翻訳したものです。（原文公開日：2009/11/11） この記事は以前のブログである"blog.fohjin.com"にて公開していたものです。 以前、2日間の講習を受けた時に、ビールを飲みながらGreg Young氏とドメイン駆動設計について語るという幸運に恵まれたことがあります。その時の話題は専ら、コマンドクエリ責務分離（CQRS:Command and Query Responsibility Segregation）パターンに関するものでした。Gregは、Eric Evans氏が著作において説明したドメイン駆動設計を受け継ぎ、主に技術的な実装を進化させています。コマンドクエリ分離（CQS）は元々Bertrand Meyer氏によって考案されたもので、オブジェクトのレベルで適用さ
state ソーシング、 event ソーシング 【スタイルの選択肢】 | システム設計日記
業務の情報の扱い方の基本スタイルとして、 * state ソーシング * event ソーシング がある。 state が先か、event が先か、という正反対のスタイル。 現在の「状態」を中心にしたスタイル。 state オンリー 一番、単純なパターン。 いわゆる「上書き」モード。 メモリ上のオブジェクトを、 setter とか update メソッドで、最新の状態を保持する。 更新前の状態は、どこにも残っていない。 テーブルであれば、update 文で、最新の状態に上書きしていくパターン。 もっとも単純だし、これで要件が満たせるなら、これで必要十分。 情報源は、「上書き」された最新の state だけ。 これが、state ソーシング のもっとも、単純な state オンリー パターン。 state - audit log パターン state を変更した時に、記録を残すパターン。 a
Event Sourcing
Capture all changes to an application state as a sequence of events. This is part of the Further Enterprise Application Architecture development writing that I was doing in the mid 2000’s. Sadly too many other things have claimed my attention since, so I haven’t had time to work on them further, nor do I see much time in the foreseeable future. As such this material is very much in draft form and
ドメインモデル駆動開発の実践 | システム設計日記
今のプロジェクト「ドメインモデル駆動開発」に、こだわって、やっている。 ドメインモデル駆動開発（DMDD:Domain Model Driven Development) は、モデリングや設計よりも、実際のコードの書き方が、主要な関心事。 やり方 具体的、かつ、簡単。 基本のアイデアは、Eclipse プロジェクトを、レイヤごとに、別々に作成すること。 （１）まず、ドメイン層のプロジェクトを作って、ドメインのクラス群を作る （２）次に、データベースを定義する （３）次に、データアクセス層の プロジェクトを別に作って、ドメイン層プロジェクトを参照する。 O-R マッピング ( SQL Map ) の仕組みを使って、ドメイン層で宣言した、 Repository インタフェースを、実装する。 （４）次に、サービス層のプロジェクトを、さらに別に作る。 このプロジェクトも、ドメイン層プロジェクトを参
システムのデッサン ： レイアウトをちゃんと考える | システム設計日記
システムをデッサン（素描）する時の、基本ダイアグラムは、 ■振る舞い系 コンテキスト図（概要のユースケースモデル） アクティビティ図（業務プロセスとプロセス間のやり取り） ■構造系 概念モデル（概要のクラス図、パッケージ図） 配置モデル などがある。 振る舞い系のレイアウト 振る舞い系は、基本的に、時間の経過とともに、振る舞いが変化することを表現している。 だから、レイアウトの基本は、時間の流れ順。 ・上から下へ ・左から右へ が普通のレイアウト。 ユースケースモデルであれば、アクタの登場順、ユースケースの発生順が基本のレイアウト。 アクティビティ図も同じですね。 システム全体のデッサンよりも詳細な設計用のダイアグラムだけど、ロバストネス図、ステートマシン図、シーケンス図なども、振る舞い系のダイアグラム。 基本のレイアウトは、時間順に、上から下、左から右。 これ、あたりまえのようで、描いて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
