DDDのドメインオブジェクトのIDプロパティ
私のドメインにはAccountオブジェクトがあります。
例えば.
class Account
{
public string Number;
public string SortCode;
}
DDDのコンテキスト内で、このアカウントオブジェクトにはIDプロパティが必要ですか？ IDは基本的にはデータベースのアーティファクトである主キーです。
場合によります。 Accountクラスをリレーショナルデータベースにマップする場合、すべてのテーブルの技術IDをPK（およびそれらのPKを参照するFK）として使用することは、良いアイデアであるだけでなく、実績のある方法です。私の経験では、すべてのテーブルの技術的なPKを「ドメインキー」（「銀行口座番号」など）から分離することは非常にうまく機能し、あらゆる種類の技術的な問題を回避するのに役立ちます。私は通常、これらのPKにIDだけでなく<class-Name>Idも付けるので、あなたの場合はAccountIDとします。
上記のクラスが、実装言語の「実際の」コード、CREATE TABLEステートメント、CRUDコードなどを生成するコードジェネレーターへの入力として使用されるだけの場合、おそらく必要ありません。クラス属性に直接ID属性を追加します。 ORMを使用する場合、ID属性をPKとして自動的に追加できるか、またはそれらのIDを手動で追加することが期待されるかは、ORMに依存します。
DDDのコンテキストでは、ドメインの専門家とモデルについて話し合うときにこれらの技術的な詳細を非表示にすることはおそらく役立つかもしれませんが、モデルの実装に対する視点を変更するときにそれらを表示します。ツールセットで、これらの異なる抽象化レベルでモデルを表示できる場合は、それを利用してください。ただし、ツールセットで許可されていない場合は、ID属性を追加して、ドメインの専門家にそれらが単なる「技術属性」であることを伝えます。
ほとんどの場合、あなたが話しているIDフィールドはデータベースによって生成されます。 RDBMSシーケンスまたは NoSQL一意の識別子 として。したがって、使用される対応するデータベースバックエンドに関連付けられます。
Persistence Ignorance/Polyglot Persistence主義 によると、このIDをドメイン集約からできるだけ隠す必要があります。
実際には、ドメインアグリゲートに既に一意の識別子が設定されている場合があります。たとえば、シリアル番号、クライアントコード、ログオン名、アカウント番号、請求書参照、または本のISBNです。
モデルにそのような「自然な」識別子がない場合、そのような本物の識別子を生成することはドメインロジックの1つの役割である可能性があります。規制によって定義されたパターン、または人にやさしい概念に従って、会社のベストプラクティスに従ってください（通常、請求書番号に年と月、またはプロセスを担当する部門の英数字の識別子を含めることが一般的です）。
Infrastructure Layer内で、特にいくつかのRBDMSテーブル間で結合SQLクエリを構築する必要がある場合は、おそらくIDフィールドを表示させます。または、ORMを使用する場合、DDD集計オブジェクトをORMオブジェクトとして直接永続化することはできませんが、「不可知論的」な変換レイヤーを使用します。これは、たとえば、独自のIDを持つDDDプレーンオブジェクトとORMオブジェクトの間に自動翻訳レイヤーを追加することにより、 私たちのDDDフレームワークが提案するもの です...ある種の「スクエアORM」： ORMマッパー上のDDDマッパー。
DDDは主にisolationについてです：データベースを考慮してドメインを汚染しないでください！集約オブジェクトフィールドにIDと名前を付けると、間違いなくにおいがします。境界コンテキストのユビキタス言語と互換性のある別の名前がおそらくあります。プレーンなIDの代わりに使用できます。
Idがデータベースのアーティファクトだとは思いません。使用しているアカウントが正しいことをどのようにして確認しますか？おそらく一意の識別子を持っているので、それは正しいアカウントです。あなたの場合、一意の識別子は「Id」と呼ばれているので、当然、それはデータベースのアーティファクトだと思います。このため、ドメインモデルにIdプロパティを含めるのはまったく問題ないと思います。
余談ですが、ドメインモデルには外部キープロパティはありません。たとえば、ドメインモデルにAddressIdを指定する代わりに、Addressプロパティを使用して、アドレスIDを含めます。