InfoQ: ドメイン駆動設計・開発の実践
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
現実世界におけるルールエンジン
これらのビジネスルールは新しいものではありません。多くのビジネスソフトアプリケーションの中核となるビジネスロジックです。もしあなたが開発者なら、こうしたルールは要件のサブセットとして表現されているのを何度となく見たことでしょう。これらは、"月曜日は、3つ以上のご注文で20%のディスカウント"や"スーパースポーツ・バイクでは、16才の男性に保険を掛けることはできません"といった文章に似ています。 ルールエンジン間の主な違いは、こうしたルールがどう表現されるか、です。プログラムの中に埋め込まれる代わりに、これらはビジネスルールの書式に符号化されます。この書式はルールエンジンごとに違っています。 ルールエンジンは、何の制限も受けていません。ルールを管理するための、他のツールと一緒にリリースされることがよくあります。一般的なオプションとしては、生成、デプロイ、保存、バージョニング、そして個別もしく
Javaガベージコレクションのエッセンス
あるアプリケーションの作業にとって、スループットは最も重要なターゲットです。1つ例を挙げると、長時間実行されるバッチ処理のジョブです。ガベージコレクションが実行されている間、バッチジョブが時々1、2秒止まっても、ジョブ全体がすぐに完了すれば問題ありません。 人間が直接対話するアプリケーションから金融取引システムまで、実質的な他のすべての作業では、システムが1、2秒か、数ミリ秒以上反応しない場合、大変なことになり得ます。金融取引では、しばしば一貫した停止時間と引き換えに、スループットを犠牲にするだけの価値はあります。物理的に利用可能なメモリ量によって制限されるアプリケーションを持ったり、footprintを維持しなければならなかったりすることもあります。そのような場合、停止時間とスループットの面の両方で、パフォーマンスをあきらめなければなりません。 以下のトレードオフは度々起こります。 大部
追悼：Steve Jobsのソフトウェアエンジニアリングへの貢献
原文(投稿日：2011/10/08)へのリンク この話をしておきたいと思います。SteveがAppleに戻る前のことですが、私たちはNeXTでミーティングをしました。私はチーフサイエンティストを連れていました。ミーティングを終えて立ち去る前、私たちはSteveが間違っているところについて説明しようとしていました。彼は明らかに間違っていたからです。でも結局はうまくはいきませんでした。ミーティングを終え、私たちは駐車場にいました。すると彼はオフィスから私たちを見つけて、わざわざここまで出てきて、さらに反論してきたのです。それはObjective-Cというプログラミング言語にまつわる技術的問題を超えていました。どうして彼がそんなに大事にしているのか、私にはわかりませんでした。これほどまでの情熱を今まで見たことはありません。(Eric Schmidt) 多くの人がSteve Jobsのことを忘れな
継続的デリバリのパターン
継続的デリバリを導入しようとする前に、いくつかの準備が必要です。真っ先に必要なのは、ビルドサーバに合うソースコード管理システムです。ビルドサーバは継続的統合を実施するサーバにもなります。ひとつひとつのチェックインをビルドできるサーバでなければなりません。一般的に言って、この用途では“既成”のビルドサーバが欲しくなります。チェックインを監視して、自動でビルドをする仕組みを構築するのは、想像以上に大変です。利用しているソースコード管理システムにフックできるトリガがあるとしても、ビルド失敗時の通知機能のような他の機能を実装するには割に合いません。 リソースが限られているとしても、継続的デリバリにとってステージングサーバは重要です。ステージングサーバは本運用環境に可能な限り似せておく必要があります。ここで第一の問題は“予算がいくらあるか”ということです。本運用環境のデータベースサーバがとても高価な
アジャイル契約
原文(投稿日：2011/02/08)へのリンク アジャイル手法に関してよく質問されることのひとつに，"アジャイル開発の契約はどのようにすればよいのか"，というものがあります。 従来のウォーターフォールモデル手法，すなわち要件を定義し，サプライヤが (自身の要求解釈とコスト見積に基づいて) 価格を提示して，両者が法的拘束力を伴う契約書にサインする，というやり方は，企業が何かを購入する場合にはとても都合のよいものです。 サインが完了すれば，次は開発期間です。開発のスコープ内に実際にあるものは何か，何が範囲外なのか，契約変更を要するものは何か，などについて全員で議論します。そうこうしているうちに開発作業が完了します。白熱した議論を繰り返した後，顧客がソフトウェアを正式に受け入れれば支払いが行われます。そして顧客は 200kg のソフトウェアを，サプライヤはお金を手にいれて，全員が – あるいはほ
InfoQ: グラフデータベース、NOSQL、Neo4j
VoldemortやTokyo Cabinetといったキー/バリューシステムにおけるモデリングの最小単位はキー/バリューペアになる。そして、BigTableやそのクローンでは可変数の属性をもつタプルに、CouchDBやMongoDBといったドキュメントデータベースではドキュメントになる。これに対しグラフデータベースでは、データセット全体をひとつの巨大な高密度ネットワーク構造としてモデル化する。 ここではNOSQLデータベースにおける2つの興味深いポイント、スケーラビリティと複雑さについて詳しく説明する。 1. スケーラビリティ CAP: ACID 対 BASE 従来のデータベースシステムのほとんどは、トランザクションに基づいてデータの完全性を保証する。トランザクションを使うことで、データ管理のあらゆる状況において、データの一貫性を確保している。こうしたトランザクションの性質は、ACID（A
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SOAガバナンスは必要不可欠のものか？それとも時間の無駄か?
Struts 1が寿命を迎える
Gartnerによるソフトウエア関連技術のハイプサイクル
CRaSH: JVMを監視するコマンドラインシェル
Sonar Quality Dashboard 3.0: 新しい商用版とDeveloper Cockpit
Senchaは、最初のHTML5/CSS3アニメーションツールのレースでAdobeの尻を叩く
OSGiコミュニティイベント
仮想パネル：最先端のJavaScriptユニットテスティング
Red HatのjBPMに新しいAPI、新しいツール、BPMN 2.0のサポートが導入される
RIA のアーキテクチャーとデザインパターン （リッチクライアント編）
Skypeの機能停止から学ぶ
Red HatがPaaSクラウドプロバイダMakaraを買収
InfoQ: ActivitiはBPMの困難を乗り越えられるか