12年後のCAP定理: "法則"はどのように変わったか
設計者は分割が発生したとき一貫性と可用性のどちらかを選ぶ必要がありますが、分割の扱い方と分割の復旧には柔軟な対処方法があります。現在のCAPの目的は特定のアプリケーションが必要とする一貫性と可用性を最適化することでしょう。このような方法には分割発生中の計画や分割の復旧計画が組み込まれています。したがって、設計者はこのような方法を採用することで、従来受け取られてきたCAPの限界を超えてCAPについて考えることができます。 なぜ"3つのうち2つ"がミスリーディングなのか CAPを理解する最も簡単な方法は分割の両側にひとつずつノードがある場合を考えることです。片方のノードだけ状態を更新できるようにすると、2つのノードに一貫性がなくなります。つまり、Cが失われます。一貫性を維持しようとすれば、一方のノードは利用できない状態であるかのように動作しなければなりません。この場合、Aが失われます。一貫性と
InfoQ: ドメイン駆動設計・開発の実践
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
仮想パネル：ソフトウェアアーキテクチャの文書化について
原文(投稿日：2009/08/10)へのリンク ソフトウェアアーキテクチャの文書化というのは、企業のアプリケーション開発プロセスにおいて重要である。プロジェクトにおけるアーキテクチャの文書化のニーズを理解する上で重要なことは、アーキテクチャの文書化がプロジェクトのライフサイクルにおいてどんな役割を果たすのか理解することだ。プロジェクトにおいて、アーキテクチャドキュメントを作成する根本的な理由は、コミュニケーションと分析と記録のためである（例えば、ある決定をドキュメントに記録しておくと、時間が経過しても失われることはない）。プロジェクトで作成するアーキテクチャドキュメントの量と種類は、そのプロジェクトで作成するプロダクトのコミュニケーションおよび分析のニーズを反映したものにするべきである。 アーキテクチャドキュメントは、プロジェクトからマネジメントへ、アーキテクトや主任設計者から開発者へ、プ
TFSの概要とアジャイル開発
Team Foundation Server (TFS) は、アジャイル開発における自動化の要請に応えるための総合的なソフトウェア開発支援システムです。アジャイル開発では短い時間で「動くソフトウェア」を完成させる必要があり、そのためにソースコードの変更歴管理、ビルド、再テストなどの作業を自動化させることが行われています。また顧客からの要求（ストーリー）の変更管理や、開発者のタスクの進捗管理をツールによって支援することも増えています。TFSでは、ソースコードやテスト結果の情報と、ストーリーやタスクの情報、その他アジャイル開発で必要とされる情報を1つの統合化されたリポジトリで管理することによって、必要なデータを1か所からすぐに取り出せるという、他の開発支援ツールにはない特徴を備えています。TFSはアジャイル開発を促進する最新のチーム コラボレーション サーバーです。必要な情報が1か所に集まって
F#の土台を越えて - 非同期ワークフロー
非同期ワークフローは、特にこの問題に対処するために導入されてきました。では、非同期ワークフローバージョンを見てみましょう。 #light open System.IO open Microsoft.FSharp.Control.CommonExtensions let openFile = async { use fs = new FileStream(@"C:\Program Files\Internet Explorer\iexplore.exe", FileMode.Open, FileAccess.Read, FileShare.Read) let data = Array.create (int fs.Length) 0uy let! bytesRead = fs.ReadAsync(data, 0, data.Length) do printfn "Read Bytes: %i
REST入門
第2版（2008年1月19日）：翻訳者による注釈を追加しました。 ヘテロジニアスなアプリケーション間の通信を実装するための「適切な」手法について議論が行われているということを、あなたは知っているかもしれないし、知らないかもしれません。そういった状況下で、現在の主流は明らかにSOAP、WSDL、WS-*仕様という世界をベースとしたWebサービスにフォーカスしています。しかし、少数派の人たちの中で、より良い方法があると主張する人がいます。それが、REST(REpresentational State Transferの略)です。本稿では、本筋から外れることなく、RESTとRESTfulなHTTPアプリケーション統合への実用的な説明を試みようと思います。これらの考え方の説明については、より詳細に踏み込んで説明をするつもりです。私の経験上、誰かが始めてこのアプローチを経験することで一番議論が活発に
RESTアンチパターン
人々がRESTに挑戦しようとすると、通常、実例を探し始めます。そして、「RESTful」であると主張している多くの実例を探したり、「REST API」と名づけたりするだけでなく、RESTを行っていると主張する特定のサービスが何故失敗するのかに関する多くの議論を集めています。 何故、このようなことが起こるのでしょうか? HTTPは新しいものではありません。しかし、それは様々な方法で適用されています。それらのいくつかはＷｅｂデザイナが考えていたことと一致していますが、その多くは異なります。人が利用する、他のプログラムによって利用される、あるいはその両方の目的でそれらを構築するかどうかによらず、あなたのＨＴＴＰアプリケーションにＲＥＳＴの原則を適用するということは、あなたがまさにあべこべのことをするということを意味します。つまり、あなたは「正しく」Ｗｅｂを利用しようとしているのです。あなたがその
InfoQ: JavaScriptへのマルチスレッド・プログラミングの導入
function backgroundLoad ( ids ) { for ( var i=0; i < ids.length; i++ ) { var a = getArticleWithCache(ids[i]); backgroundLoad(a.children); } } このbackgroundLoadはIDの配列を引数に取り、その各IDに対して上で定義したgetArticleWithCacheを呼び出します。これでIDに対応する記事のデータがキャッシュされます。そして読み込んだ記事の子記事のIDに対してbackgroundLoadを再帰的に呼び出すことで、ツリー全体をキャッシュすることができます。 ここまですべてうまくいっているように見えます。しかし、一度でもAjax開発を経験したことのある方ならば、これではうまくいかないということはすでにおわかりだと思います。これまでの例で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版