2016年1月26日デジタルとアナログ。2016年1月12日2016年あけましておめでとうございます。康廣ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。今回は、ドメイン駆動設計における、エンティティの識別子の実装面について考えてみたいと思います。(あまり本質的な話題でなくてすみません。)エンティティの識別子、どう実装していますか?私の場合、以下の図のようにエンティティが直接LongやStringなどプリミティブの型で持ってもよいと思っていました。エンティティの識別にしか使われないのでエンティティが直接持っていた方が使いやすいと思っていたのです。ドメイン駆動設計本の例はどうでしょう・・・。ドメイン駆動設計ではプリミティブの型を使用している例も載っていますが、書籍内のサンプルを実装したDDDSampleではVoyageNumberやTrackingIdなど識別子をラップしたクラスを使ってます。実践ドメイン駆動設計本では日付時刻を含んでいるような識別子を例にあげてこのような複雑な識別子はラップしたクラスを使うべきとあります。要は識別子の複雑さや使われ方によるのかなと思います。いう曖昧な結論では記事になりませんので、識別子用のクラスを持つことで効果がでるケースを紹介したいと思います。例は、よくある求人サイトの想定で、求職者が求人に応募するようなモデルです。求人パッケージ(モジュール)。求職者パッケージ(モジュール)。求職者は求人に応募しますので、応募クラスは求人IDクラスを持っています。・・・と、クラス図だけではなんてことないのですが、パッケージ図を見るとこうなります。これが求人や求職者の識別子がプリミティブな型の場合は以下の通り依存関係を持つことはありません。実装上はこれでも問題ないのですが、ドメインの知識をソースコードに反映するということを考えると、パッケージ間の依存関係がきちんと表現できるとよりわかりやすい設計になると思います。エンティティの識別子はそのエンティティの同一性を保証してあげるだけの役割ですので、わざわざラップして使う必要がないと思いがちです。ラップして使うことで、プリミティブな型をそのまま使うことに比べてモデルをより豊かに表現することができ、ドメインの知識をより深く理解する手掛かりとすることができます。コメントをキャンセルコメントを入力してください。以下に詳細を記入するか、アイコンをクリックしてログインしてください。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。アカウントを使ってコメントしています。新しいコメントがついたらメールで通知。Blog.投稿先:キャンセル。