果物を表すValueObjectを書く必要があり。
すでに下記のDBレコードが存在すると仮定した場合。
果物テーブル
id | name |
---|---|
1 | りんご |
2 | みかん |
3 | バナナ |
出荷テーブル
id | fruit_id(果物ID) | volume(出荷個数) |
---|---|---|
1 | 1 | 10 |
2 | 2 | 5 |
3 | 3 | 20 |
ValueObject内の定数の定義は、下記のように名称で持つべきでしょうか?
php
1class Fruit { 2 const APPLE = 'りんご'; 3 const ORANGE = 'みかん'; 4 const BANANA = 'バナナ'; 5 ... 6}
もしくは、IDで持つべきでしょうか?
php
1class Fruit { 2 const APPLE = 1; 3 const ORANGE = 2; 4 const BANANA = 3; 5 ... 6}
私の考えでは、ドメインはDBの影響を受けないという原則があり、その観点で見ると
Entityの識別子は除外してIDはDBの都合の物であり、名称がドメインの本質だと考えますので、名称で持つべきだと思っています。
ですので、出荷Entityが下記のような場合で、Repositoryで永続化する場合にFruitを名称でもつと、IDへの変換を行う必要がありますが、
それもDDDを実践する上で必要なコストだと考えています。
php
1class Shipping { 2 private int $id; 3 private array $fruits; 4 private int $volume; 5 ... 6}
さらに、DBのid:3,name:バナナ
が id:3,name:ばなな
に変更されても、
ValueObjectの const BANANA = 'バナナ';
を const BANANA = 'ばなな';
に変更は行ってはいけないと考えています、
DBの変更の影響を受けてValueObjectを変更する理由にはならないと考えている為です。
出荷Entity永続化のIDへの変換にて名称のズレが問題になりますが、それもインフラ層にて名称の変換を行い保存するべきと考えています。
しかし、データベースのレコードIDをドメインの意味があるものとして捉えれると考えた場合は、これらの変換対応コストが不要になります。
果物テーブルのIDはドメインとして意味があるものでしょうか?
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。