このgithubでは、 https://github.com/johnph/simple-transaction の下にTransaction.Framework
プロジェクト、エンティティがあります(データ/エンティティにあります)
ドメインフォルダーには、ドメインモデルがあります。
私が観察したところによると、ドメインモデルはビジネスロジック検証のような他のほとんどすべてに使用されている一方で、エンティティは主にリポジトリに使用されています。これはドメイン駆動設計と呼ばれていますか?
これは残念ながらDDDの一般的な形式です。残念ながら、DDDの中核的な原則、つまり問題の実際のモデル化を完全に無視しているためです。
純粋なデータ構造を持つことは、何が起こっているのか、どの問題が解決されているのかを読者に伝えることは何もしません。取得/設定するので、ユビキタス言語を使用しませんしませんものは問題の一部であってもめったにありません。
あなたが単に リポジトリの構造を見る の場合、作成者はavoidでドメインに関連するすべてのことについて言及するのに多大な努力をしたようです手。これは、発生するはずの事態の正反対です。毎回、ビジネスピアが使用する正確な用語の使用に集中する必要があります。
これは、ドメインモデルと永続性モデルの厳密な分離であると私は見ています。このモデルを複製することにより、特定の目的のためにモデルを微調整することが可能になります。 1つはビジネスルールを表し、もう1つは永続化とクエリが簡単です。それが単一のモデルである場合、2つの間のトレードオフを行う必要があります。
これは、DDDを実装する特定の方法です。プレーンDDDでは、ドメインエンティティを永続化する方法については何も触れていません。それは二次的な懸念と考えられています。 DDDでは、ドメインエンティティについてのみ考え、それらのエンティティがどのように永続化されるかは別の場所で決定されます。
しかし、この特定の実装の場合、1つ間違っている点があります。 DDDでは、リポジトリはドメインモデル自体の一部です。つまり、リポジトリは永続エンティティではなくドメインエンティティで機能する必要があります。しかし、それがここで起こっていることです。ドメインから永続エンティティへの変換はサービスで発生しますが、これを行うのは間違っています。リポジトリ内で発生するはずです。このようにして、リポジトリの実装の詳細になります。このように、リポジトリがEF、プレーンSQL、または実際にデータを永続化するために別の何かを使用している場合、リポジトリのユーザーには関係ありません。
上記の例は/ src/Frameworks/Transaction/Services/TransactionService.csinメソッドCreateTransactionAndUpdateSummary
(using AutoMapper ):
// transform domain entity to persistence entity
var accountTransactionEntity = _mapper.Map<AccountTransactionEntity>(accountTransaction);
var accountSummaryEntity = _mapper.Map<AccountSummaryEntity>(accountSummary);
// call repository with persistence entities
await _accountTransactionRepository.Create(accountTransactionEntity, accountSummaryEntity);
var currentSummary = await _accountSummaryRepository.Read(accountTransaction.AccountNumber);
// transform persistence entity to domain entity
var result = _mapper.Map<TransactionResult>(accountTransactionEntity);
上記のコードは、サービスではなく、リポジトリ自体の中にある必要があります。