DDD
DDDとは、Domain Driven Desingの事。
ドメイン駆動設計ですな。
↑はQuicklyだが、Domain-Driven Designと直球本(以下、DDD本)も出ている。
あんまし理解してないんだけど、理解を深める意味も込めてエントリに仕立ててみる。
参考：
http://handsout.jp/slide/371
http://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html
↓で○章とか言っているのはこの内容の事。
まず、ドメインっていうのは、業務に関することを実現している部分のこと。
つまりは、コアなロジック全般を指す。
DDD本は、デザインパターンやアナシリスパターンなどと同じく、
パターンの本なのだが、コードよりの話ではない。
その根底は思考過程をパターン化したような本なので、そこを間違えないように。
DDD本で提起しているDDDの基本方針は、
の3つ。
どれも、コードより、思考過程や開発過程での設計指針を指す。
まず、ユビキタス言語。
これは、ドメイン(≒業務知識)を共通言語と同じように使えるようにプロジェクトを回しましょうってこと。
メタファ(喩え)とかを有効に使って、みんながみんな業務知識を同じように理解しましょう。ってことかな。
つぎに、モデル駆動設計パターン。
これは、上で定義されているドメインをそのままコードに落とし込みましょうってこと。
これで、コードとユビキタス言語の整合性が取れる。
最後に実践的モデラーパターン。
これは、一言で言ってしまえば、設計者＝コーダってこと。
設計はA君がやって、コードの実装をB君がやったのでは、ユビキタス言語という前提が崩れてしまうため。
実際は、設計者＝コーダで無くてもいいが、プロジェクトに関わる全ての人が共通の土台に立った上で開発を行うべきということだろう。
DDDの実装はMDD。
DDDの根底は思考過程・考え方の話なので、実装とはあまり関わりが無い。
なので、実装に近い部分にはMDD(Model Driven Design モデル駆動設計)を用いる。
2章以降がMDD寄りの話。
2章の
Layered Architecture（層状アーキテクチャ）パターンから始まり、
Repositories（リポジトリ）パターンまでは、
MVCパターンとか、O/Rマッパーとかを根底に、それらをどう組み合わせてスマートに実装するかについて主眼に置いている。
これらは、StrutsやSeasar2系の一般的なフレームワークを(それらを理解した上で)使ったことがある方にはお馴染みのパターン。
3章、4章は
ドメインの周囲に散らばるクラス群についての設計指針だ。
これは、技術的設計上、非常に参考になる。(ちゃんと読んでないけどw)
ということで、駆け足でまとめてみた。
私自身しっかりと理解しているわけではないが、
現状、ドメインロジックの実装には、
トランザクションスクリプトが用いられる場合がほとんどで、
私自身、ドメインモデルをしっかり使った実装というのを見たことが無い。
動向を見守りつつ、今のうちに基本をしっかり押さえておくのが一番か。
