ドメイン駆動設計についてのお勉強を自分なりにざっくりメモ

エヴァンスの書籍を読んでお勉強した。

まず、おさらいに、索引を眺めたらいいかなと思ってやってみた。気になる用語をピックアップ。

キーワード（一般）

DDDで導入される概念と言うより前提の用語

副作用と関数

副作用を起こさずに結果を戻す操作は関数と呼ばれる

コールバック・オブザーバ

書籍では、「レイヤを関連づける」の項で出てきた。
レイヤは上下関係があるためにこのパターンが有用になる。

アトミック（不可分）なメソッド

ファクトリについての文脈で出てきた
必要十分にコンパクトに関数やメソッドをまとめるってことかな
ファクトリなのに何度もメソッドを実行するとか、余分なものも生成しちゃったらダメということかな。

ファザード

腐敗防止層の文脈で出てきた

"ファザードとは、サブシステムのための大体インターフェイスで、クライアントのためにアクセスを簡略化して、サブシステムを使いやすくする。"

Gofのデザインパターンのファザード（主に適用例を参照）
http://ja.wikipedia.org/wiki/Adapter_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

ファザードとアダプタの委譲を使った場合は似てるかなと思ったが、
ファザードはサブシステムを使ってロジックを実装している。

アダプタ

腐敗防止層の文脈で出てきた

"アダプタとは、ふるまいを実装している側が理解しているものとは別のプロトコルを、クライアントが使えるようにするためのラッパである。"

Gofのデザインパターンのアダプタ（主に適用例を参照）
http://ja.wikipedia.org/wiki/Adapter_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

継承（extends）、委譲（内部でnew）を利用した場合の２つがある。
どちらの場合もインターフェイスを定義している。

ファザードとアダプタの委譲を使った場合は似てるかなと思ったが、
ファザードはサブシステムを使ってロジックを実装している。

書籍では、Gofデザインパターンよりユルイ定義（より概念的）で使われた。

アナリシスパターン

http://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%8A%E3%83%AA%E3%82%B7%E3%82%B9%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

"ある実際上の文脈で有用な考え方であり、おそらく他の文脈でも有用なもの"
"実際のソフトウェア上の実装形態ではなく、ビジネスプロセスの概念的な構造"

実装よりももっと概念的な部分での設計パターンって事かな。
書籍では、このときに用語の取り扱いには注意するように書いてあった。

コンポジット仕様、コンポジットパターン

木構造を伴う再帰的なデータ構造を表すのに使えるパターン。
とても粒度が小さいオブジェクトの実装に対して有効。

Gofのデザインパターンのコンポジット
http://ja.wikipedia.org/wiki/Composite_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

addComponent()でデータ構造を構築していっている。こういう仕様のことかな。
例えば、add(),append(),plus(),delete(),remove()とかで木構造をつくるみたいな。

ポリシー、ストラテジー

Gofのデザインパターンのストラテジー
http://ja.wikipedia.org/wiki/Strategy_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

"アルゴリズムを実行時に選択することができるデザインパターンである。"

http://ja.phptherightway.com/pages/Design-Patterns.html
http://ja.phptherightway.com/pages/Functional-Programming.html

コールバックだったりクラス定義されたストラテジーを実行時に選択（遅延束縛と同義？）する。
このへん、よく分かってない。

束縛（バインディング）

これは書籍に出てきたというより、上記の「ポリシー、ストラテジー」にでてきたので。

http://koriym.github.io/binding/

"Dependency Injectorがインジェクト ＝早期束縛"
"AOPのアスペクトがインジェクト =遅延束縛"

http://ja.wikipedia.org/wiki/%E6%9D%9F%E7%B8%9B_(%E6%83%85%E5%A0%B1%E5%B7%A5%E5%AD%A6)

"静的スコープにおいては、名前束縛はプログラム実行前に行われる。これを静的束縛 (static binding) もしくは早期束縛 (early binding) と呼ぶ。動的スコープにおいては、名前束縛はプログラム実行中に行われる。これを動的束縛 (dynamic binding) もしくは遅延束縛 (late binding) と呼ぶ。"

宣言的設計

宣言に沿った仕様の処理を生成するような処理にする設計。
コンパイルやリフレクションでの実装もありうる。

http://d.hatena.ne.jp/asakichy/20110615/1308089411

"永続化やＯ/Ｒマッピング"
"宣言的な形式をとる興味深いアプローチに、ドメイン特化言語があります。"

フライウェイトパターン

シングルトンはフライウェイトの一種。
ドメインモデルにはマッチしないデザインパターンの好例として挙げられている。
コンポジットのほうが、モデルと実装の両方、また、値オブジェクトとエンティティの両方、にパターンを適用できる。
たぶん、パフォーマンス的にフライウェイトの方が望ましい場合もあるんだとは思う。

Gofのデザインパターンのフライウェイト
http://ja.wikipedia.org/wiki/Flyweight_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

"等価なインスタンスを別々の箇所で使用する際に、一つのインスタンスを再利用することによってプログラムを省リソース化することを目的とする。"

レイヤー、レイヤー化アーキテクチャ、ティア、多層アーキテクチャ

水平方向（物理階層）の分割はティア、垂直方向（論理階層）の分割はレイヤー。
たぶん、同じドメインのオブジェクトを水平に別オブジェクトに分けると大変だから
それはやらないほうがいいということかな。

http://ja.wikipedia.org/wiki/%E5%A4%9A%E5%B1%A4%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3
http://d.hatena.ne.jp/masapon1967/20060907/1157624292
http://www.atmarkit.co.jp/fdotnet/architecture/aafn05/aafn05_01.html

書籍では、「インフラストラクチャ駆動パッケージングの落とし穴」の項あたりを参照。

XP、エクストリームプログラミング

ざっとみたところとてもよさそうだ。
産業としての位置づけと労働環境としての位置づけを踏まえた視点をもった開発手法かと。

http://ja.wikipedia.org/wiki/%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%88%E3%83%AA%E3%83%BC%E3%83%A0%E3%83%BB%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0

"柔軟性の高い開発手法であるため、難易度の高い開発やビジネス上の要求が刻々と変わるような状況に向いた開発手法である。事前計画よりも柔軟性を重視する。"
"XPはドキュメントよりもソースコードを、組織的開発の歯車となることよりも、個人の責任と勇気を重んじる人間中心の開発プロセスであるとしている。"
"プログラマがXPを好む理由は、このようなプログラマの不安を解消する仕掛けを具体的なプラクティスとしてさまざまに備えているためである。"

セマンティクス（意味論）

"コンピュータに文書や情報の持つ意味を正確に解釈させ、文書の関連付けや情報収集などの処理を自動的に行わせる技術について用られる語である。"
"モデルは言語のセマンティクスを提供し、技術的な開発が出来るくらいの正確性もある糊の役目を果たす。"

プログラム意味論（program semantics）
http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E6%84%8F%E5%91%B3%E8%AB%96
表示、操作、公理の意味論が大きな分類として挙げられている。


http://www.itmedia.co.jp/enterprise/0108/20/01082088.html
シンタックスのようなコードの記述としてではなく、マークアップの構造のような意味論の記述をセマンティクスと呼ぶというようなことが書いてる。

まだすこし理解ができているか分からないがそういう感じなのかな。

キーワード（DDD）

DDDで導入される概念の用語のうちから、コンパクトにピックアップ

境界付けられたコンテキスト

「境界付けられたコンテキスト」は特定のモデルが適用できる範囲にとどめられる。
 「アプリケーションに特有の部分」が持つ用途やコードベースやデータベーススキーマなどの物理的な表現の観点から設定する。プロジェクトと最終成果物の両方をみて設定する。
シンプルな場合には、名前空間の区切りと同じかな。

コンテキストは第4部の戦略的設定にて、３つのテーマ（コンテキスト、蒸留、大規模な構造）の中で、最もわかりにくいが、最も根本的なもの。

外部と内部的なコンテキスト構造を地図にしたものをコンテキストマップと呼ぶ。
これをつくるのは大事。

次に気になることについてまとめる

エンティティ・値オブジェクトかどうかの判断

エンティティは同一性があるオブジェクト。一意性がIDを振ることができる。
ただ、ユニークキーがあるかのような機械的なものではなく、ドメインを理解して、照らして判断される。

エンティティではないオブジェクトが全て値オブジェクトかというとそうでもないみたい。
ドメインにおける記述的な側面を表現し、概念的な同一性を持たない場合に値オブジェクトと呼ばれる。

なんか、書籍を読み進めるうちに、この説明でつじつまが合わないんじゃないのかというような気がした部分があった気がしたけど覚えていない。多分わたしの理解が間違ってるんだけど、ひとまず保留。

上記の保留を後に検討。
自由席はエンティティではない。は、まだわかりやすい。全ての席が似てるイメージだから。
配送仕様がエンティティではない。は、今ひとつわかりにくい。それら仕様はそれぞれ異なるイメージだから。
異なる貨物で、配送仕様を共有できるからというのが、理由とされる。
しかし、配送仕様は置き換えは可能だが、交換すると意味が変わってしまう。これは同一性な気がするけど。
置き換えをしても、違反ではないということかな。紐付けが変わって挙動も変わるけどエラーは出ない。
輸送機器移動や荷役イベントは、一意に貨物と紐尽く。
分かった気がする。

上記のようなことを考えるので、
紐尽くオブジェクトについて、エンティティの判定はルートのオブジェクトの判定と少し違う気もした。

if(タイプチェック(配送仕様)==値オブジェクト)
{
    return true;
}
function タイプチェック(val){
    ???;
}

関係データベースとリポジトリ

関係データベースを使うと深い複合オブジェクトの構造に事実上の制限が設けられるという意味がわからない。
具体的に関係データベースの形に、例えばアダプトできないオブジェクトの構造ってどういうのだろうか。
それとも、アダプトとか何らかの1ステップ処理が入ることが既に制限という意味か。

関係データベースとORMつかう（使いこなせてはいない）のが普通になっているとわからないのかな。

関係データベースやファイルなど、・・・オブジェクトのかたちに再構成しなければならない。
・・・
多くの人はリポジトリのことをファクトリであると考える。・・・新しい概念オブジェクトを生成することとは違う。

リポジトリがオブジェクトの生成をファクトリへ委譲するのがよい。

ドメインオブジェクトと集約について（集約の不変条件）忘れたのでおさらい

• 集約へのアクセスはルートにする
• ルートには1エンティティ
• 集約境界の内部は値オブジェクトと、局所的（ローカル）な同一性をもつエンティティ
  • （果たしてエンティティと呼んで良いのか）
  • （ローカルの同一性対グローバルの同一性とオブジェクト参照）の図がある
  • 逆にいえば、ある集約内にグローバルな同一性のエンティティは入れられない（七章で出てくる）

システムを線引きする概念を混同しないように考える

• 集約
• コンテキスト
• モジュール
  • 単にパターンではなく凝集度の高いものを集める
• プロジェクト
• パッケージ
• レイヤー
• ティア

実践につなげるにはどうするか

• DDDを踏まえたフローで開発＞XPかな
• 参照の方向の制約について認識が足りないので気をつける