『Domain-Driven Design』
Eric Evansの書籍『Domain-Driven Design』は、ドメインモデリングやピュアなオブジェクト指向開発の指南書として誉れ高く、ドメインモデルベースでアプリを開発したいときはぜひとも一読したい本だ。このようにDDDは、1アプリレベルのドメインモデル構築に関するものと思われがちだが、実際はその後半部分は単なる1アプリのレベルを超えた話になっていて、アプリケーション統合（EAI）やSOA、エンタープライズアーキテクチャにまで広がる射程をもった設計思想を語っている。 Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software SOAはいま大流行しているが、SOAで本当に重要なのは、メッセージングやWebサービス、ESBを使うといった技術的な問題などでは全然なくて、サービスベースのア
Martin Fowler's Bliki in Japanese - Evansの分類
http://martinfowler.com/bliki/EvansClassification.html Eric Evansのエクセレントな著書『Domain Driven Design』では、 我々がしばしば目にする様々なドメインオブジェクトが以下のように分類されている。 エンティティ：アイデンティティを持ち、時間経過によって形を変えるオブジェクト。「リファレンスオブジェクト」とも呼ばれることがある。 バリューオブジェクト：属性の組み合わせに意味があるオブジェクト。同じ値（バリュー）を持つ2つのバリューオブジェクトは、どちらもすべての属性が等しいと見なされる。バリューオブジェクトについては、私もP of EAAで触れている。 サービス：ドメインにおける独立したオペレーション。サービスオブジェクトは1つ以上のサービスを持つ。実行文脈におけるサービスオブジェクト型のインスタンスは、通常
Shared Kernel パターン は、たぶん アンチパターン | システム設計日記
二つの Bounded Context を、別のチームで開発していると、コードやデータベースにかなり重複が目立つことがある。 Shared Kernel パターンは、そういう状況を改善するために、 ・特に重複がひどい箇所を、共通化すべき領域として特定し ・２つのチームが相談しながら ・共通モジュール（Shared Kernel) を開発・維持する ことに取り組もう、というやり方ですね。 なぜ、そういう状況が起きるか? 別の Bounded Context なのに、なぜ、そんなに重複が多いか？ 本来は、ひとつの Bounded Context として扱うべき問題を、なんらかの事情で、２つのチームに分けて開発しているからなんだと思う。 ありがちなケースは、開発メンバーは大勢いるが、経験不足・スキル不足のメンバーが大半、という状況。 １０人のメンバーが、ひとつのチームとして開発するのは、現実的で
Value Object は不変にする | システム設計日記
ドメイン駆動設計(DDD)の Value Objects パターンでは、オブジェクトを不変(immutable)にすることを強く推奨している。 なんとなく、そんなもんか、と思っていたけど、ある日、なるほど、というケースに出くわした話し。 変数名にこだわる 前提として、変数名にこだわるようになったことがある。 DDD のユビキタス言語パターンの実践として、 ・パッケージ名 ・クラス名 ・メソッド名 ・変数名 は、業務上の意味のある名前にこだわることを、徹底しはじめた。 Java Calendar クラスの日付計算 当日から、２週間後に、期限切れになる、というビジネスルルールを実装していた。 Calendar getExpireDate() { Calendar now = Calendar.getInstance(); now.add( Calendar.DATE, 7*2 ); retur
ドメインモデルに関して - ひたすらプログラミング日記
ドメインモデリング能力を鍛える - じゅんいち☆かとうの技術日誌 ドメインモデルに対する日米の温度差 | Ouobpo 上記の素晴らしいエントリーを読んで個人的に思ったことをつらつら書いてみようかなと。 個人的に日本でドメインモデルが主流にならない理由の1つとしてアジャイル開発プロセス（XP、スクラム、リーン等）の普及度合が低いというのも大きな理由の1つなのではと最近よく感じています。なぜならMartin Fowler、Kent Beck、Eric EvansやDavid Tomasらは彼らが執筆した本の中でインクリメンタルであり進化的な設計を推奨し、テストケースとリファクタリングを行うことで洗練されたクラス設計が出来上がると述べています。そして、それらの工程（テスト、リファクタリング、進化的設計等）はアジャイル開発ではほぼ必須と言っていいプラクティスです。 対してウォーターフォール開発で
Factories パターン：コンストラクションは分離せよ | システム設計日記
ドメイン駆動設計の Factories パターンも、大きな発想の転換だった。 ドメインオブジェクトのコンストラクションは、別のオブジェクトの責務にするのが良い。 ちょっとびっくりしたけど、説明を読むと、なるほど、と納得。 空っぽのオブジェクトと setterで作る ドメイン駆動設計に出会うまでのやり方がこれ。 Customer customer = new Customer(); customer.setName( name ); customer.setContactInfo( contactInfo ); ... という感じで、 ・デフォルトのコンストラクタで、空っぽのオブジェクトをつくる ・後から、中身を setter で埋めていく というのがあたりまえだと思っていた。 (サンプルプログラムって、ほとんんど、そうなっていません？) 初期値はコンストラクタでセットすべし ドメイン駆動設
Specification パターン ：複雑な ビジネスルールの表現手段 | システム設計日記
Domain-Driven Design(DDD)の９章 "Making Implicit Cocepts Explicit" ( はっきりしない概念を明確にする) では、かなりのページを使って、Specification パターンを説明している。 ・仕様を満たすこと ・こういう条件を満たすこと という種類のビジネスの約束事を表現するドメインオブジェクトの設計・実装パターンの議論。 エバンスは、このパターンがお気に入りらしく、１８ページを使って解説している。 はっきりしない概念として取り上げた「制約(ビジネスルール)」と「業務手順」の議論は、たったの４ページなのにね。 動機：複合条件を表現する 単純な if 文で判定できる場合は、良いけど、 ( Java 経験５年以上 OR C# 経験５年以上) AND ( 東京在住 OR 転居可能 ) AND ( 文系 OR 読書好き ) AND ( 好
さわるのが楽しいコードを設計しよう | システム設計日記
Domain-Driven Design(DDD)の１０章 "Supple Design (しなやかな設計)"は、この本の中では、ちょっとかわった章です。 この章だけは、 ・開発者の視点で ・開発者のための良い設計 にフォーカスしている。 業務の専門家にとってどうか、とか、ソフトウェアの利用者にとってどうか、という議論はまったくでてこない。 ある意味、ドメイン駆動設計らしくない章になっている。 （もちろん、開発者にとっては、面白いし、参考になる内容ばかり） 良い設計ってなんだ 良いソフトウェアは、利用者にとって役立つこと。 でも、この章では、良いソフトウェアのもう一つの側面、「開発者にとって良いソフトウェア、良い設計」に焦点をあてている。 キャッチフレーズは、 "a design that is a pleasure to work with" ふれるのが楽しくなるコード、という感じですか
Conceptual Contours パターン : ドメインオブジェクトの粒度 | システム設計日記
オブジェクトの大きさは、いつも悩ましい問題。 Conceptual Contours パターン ( 概念の輪郭線 ) は、ドメインオブジェクトの粒度をうまく設計するための手がかり。 やりがちな方法 まずは、粒度設計の、やりがちな方法を三つ。 みじんぎり とにかく小さくわける。 小さな部品だと、どこでも、いつでも手軽に利用できる。 部品は小さいほど、再利用しやすくなる。 コンピュータがそもそも、bit という最小単位を扱うから、多目的に使える。 でも、なんでも bit で考えるのは、さすがにしんどい。 大きな塊 オブジェクトは、複雑な処理やデータ構造を、内部に隠蔽してくれるから、役に立つ。 「顧客登録」とかの単位で、どーんとひとつの塊にして、詳細を隠蔽すれば、利用しやすい。 でも、ばっかでっかいクラスだと、どこで何をしているのか、理解するだけでも一苦労。 お隣を見れば、もうひとつ、顧客がらみ
Standalone Classes パターン : スパゲティにしない設計 | システム設計日記
たくさんのオブジェクトが、からみあってくると、ソフトウェアは手がつけれなくなる。 いわゆるスパゲティコード。 ・読みにくい（理解しがたい） ・テストコードが書きにくい（特に、セットアップ） ・変更がしにくい／こわくてできない ．．． スパゲティにしたいわけじゃない。でも、いつのまにか、そうなっちゃう。 こうならないために、どんな設計・実装をこころがけるべきか？ 「依存」を見たら、泥棒と思え 当たり前のように使っている、コードの中の依存関係。 ・インスタンス変数で他のオブジェクトへの参照を保持 ・メソッド内の一時変数で他のオブジェクトへの参照を保持 ・メソッドのパラメータで渡ってくる、他のオブジェクトへの参照 ．．． こういう「依存性」を、すべて疑ってかかる。 スパゲッティになりたくなかったら「全て」を疑う。 「ほんとうに必要か？」 「他のやり方があるのでは？」 参照やパラメータ渡しがあるか
import 文で結合度をチェック する | システム設計日記
ドメイン駆動設計(DDD) の Standalone Classes パターンは、クラス間の依存を少なくし、疎結合にするのがテーマ。 私は、コードレビューの時、この結合の度合いは、かなり気にしてチェックしています。 といっても、そんなに難しい話ではなく、Java だったら、 import 文の数を見るだけ。 import は、クラスごとに宣言 コーディングの約束ごととして、import は、必ずクラス単位で宣言する。 "*" を使って、パッケージ全体の import 指定は不可。 こういう import 文の構成は、IDE が面倒みてくれるので、楽チンですね。 import に行数が多い コードの中身をみなくても、先頭の import 宣言の行数を見れば、「結合」の度合いは一目瞭然。 ・import が少ないほど、疎結合。(もちろん、良い設計) ・import が多いほど、密結合。（もちろ
jdon: Jdon Framework
JiveJdon 3.2 released! 2008-07-24 JiveJdon3.0 is a opensource forum/BBS software that based on JdonFramework5.0 and modeling by Evans DDD, its database schema is same as jive2. running url: http://www.jdon.com/jive/forum/forumList.shtml JdonFramework5.2 realesed 2008-04-02 Add support Hibernate3 lazy function, struts+jdon+hibernate is more simple and easy than struts+spring+hibernate. Jdon's cach
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
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）は、「
bliki: Anemic Domain Model
This is one of those anti-patterns that's been around for quite a long time, yet seems to be having a particular spurt at the moment. I was chatting with Eric Evans on this, and we've both noticed they seem to be getting more popular. As great boosters of a proper Domain Model, this is not a good thing. The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: Domain-Driven Design: Tackling Complexity in the Heart of Software: Evans, Eric: 本
http://www.scribd.com/doc/12923720/Domain-Driven-Design
Domain Driven Design.pdf - eBook and Manual Free download
http://www.infoq.com/resource/articles/ddd-in-practice/ja/resources/ArchitectureDiagram_lg.gif
Domain Driven Designに関するすべてのコンテンツ
