InfoQ: ドメイン駆動設計・開発の実践
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
- データベースの進化的設計
データベースの進化的設計 Martin Fowler Pramod Sadalage 原文(Evolutionaly Database Design) ここ何年かで私たちはアプリケーションの開発に即してデータベースの設計を進化させることを可能にする技法を編み出した。このことはアジャイルメソッドにとって非常に重要である。この技法は継続的インテグレーション及び自動化されたリファクタリングをデータベースの開発に適用し、かつDBAとアプリケーション開発者が密接に協力することによって成り立つ。この技法は開発中のシステムや既に開発されたシステムに対しても機能する。 変化に対応する 制限事項 プラクティス集 DBAは開発者と密接に協力し合う 全員が自分のデータベースインスタンスを保有する 開発者は共有マスターに頻繁に結合する スキーマとテストデータから成るデータベース すべての変更でデータベースのリファ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版
