はじめに
ドメイン駆動設計入門を読んでみて、DDDを学ぶメリットやそれぞれのパターンについてまとめていく。
ドメインオブジェクトを定義するメリット
「コードのドキュメント性が高まり、ドメインにける変更をコードに伝えやすくする」
ソフトウェアを作る製造過程よりも、その後の保守開発に効果を発揮する。
ざっくり噛み砕いてみる
Q.開発者がプロジェクトに途中で参画したり、引き継いだ時は全く知識がない状態でどのようにソフトウェアの用件を知るのか。
=>多くの場合は仕様書などのドキュメントを頼りにする
=>しかし、そのドキュメントはコードと直接紐づくわけではないため、ドキュメントが更新されていなくてもソフトウェアには問題を引き起こさない。
=>度々ドキュメントが役に立たないことがある。
=>開発者は結局のところコードを手がかりに仕様を知ることになる。
=>ドメイン駆動設計ではドメインオブジェクトとして実装することで、「無口なコード」になることを防ぐ。
★振る舞いを持ったオブジェクトはそのソフトウェアがどのドメイン知識に関心があり、それをどのように識別しているかを明確にする。
これが後続の開発者がドメイン知識を理解する有効な手段となっていく。
ドメインオブジェクトのエンティティについて
エンティティの性質
①可変である
②同じ属性であっても区別される
③同一属性により区別される
①可変である
エンティティは値の交換による変更は行わない。エンティティの属性を変更したい時は、その振る舞いを通じて変更することになる。
そもそも振る舞いって？...
=>淡白にsetterなどで属性の値を交換を行うのではなく、メソッド名で何を変更できる振る舞いなのかを明記する。
※ エンティティは全ての値を可変にする必要はない。むしろ可能な限り普遍にしておく方がベター。
ユーザーエンティティの氏名の属性を変更したい時は氏名を変更するためのメソッド（updateNameメソッド）を作成して変更できるようにする。
②同じ属性であっても区別される、③同一性をもつ
人間には名前や身長体重などの属性がある。それが一つ変わっただけで、その人は違う人に変わってしまうのか。もちろん変わらない。
=>同一性を担保するものが存在するということ。
これをシステムに置き換えると、新規ユーザー登録した人のユーザー情報を変更を行い、氏名を変更すると別のユーザーになってしまうのか。
=>多くのシステムではIDなどで一意に決まるため、ユーザー自体が変更されるわけではない。
この時、ユーザー情報は同一性によって識別されている状態という。
エンティティ同士を区別するために識別子が利用され、値オブジェクトのように等価性で判断されない。
エンティティのライフサイクル
何を値オブジェクトとして、エンティティとするかの判断基準
=>エンティティはライフサイクルが存在し、連続性が存在する。
ユーザーは新規作成されてから生を受け、時間が流れてそのユーザー登録が利用者にとって不要となったときに死を迎える。これはユーザーはライフサイクルを持ち連続性を持つということ。このためユーザーはエンティティとして定義すべき。
参考：ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本