3

ユーザーによる変更の全履歴がアーカイブされるように、エンティティのバージョン管理を含むプロジェクトに取り組んでいます。

基本的には、エンティティが作成されると、その内容のバージョン 1 もアーカイブ テーブルに保存されるという考え方です。エンティティが変更されるたびに、増分バージョンも保存されます。

エンティティの状態のアーカイブ テーブルへの保存は、 によって処理されますArchiveService。

エンティティが永続化されている場合、バージョン 1 を作成するために ArchiveService を呼び出す必要があるため、最も論理的な方法は、リポジトリからそれを呼び出して、サービスを依存関係としてリポジトリに渡すことです。

public class Repository {
    private ArchiveService archiveService;

    public Repository(ArchiveService service) {
        this.archiveService = service;
    }

    public void add(Entity entity) {
        // ... (persist the entity)

        this.archiveService.createVersion(entity);
    }
}

これは良い習慣ですか、それとも欠点はありますか? 私がこれまで見てきたのは、リポジトリに依存するサービスであり、その逆ではありません。

4

2 に答える 2

3

説明したようにモデル化すると、ドメインの知識を暗黙的にして、それ自体はドメインの一部ではないリポジトリに隠します。これは良い考えだとは思いません。

Domain Eventsを使用してモデル化できますEntityCreated。イベント リスナーは、イベントを取得して、それぞれのアーカイブ エントリを作成できます。

コメントで提起された質問に答えるために更新します。

概念的には、リポジトリは、データ ストアに永続化された一連のオブジェクトとそれらに対して実行される操作をカプセル化し、永続化レイヤーのよりオブジェクト指向のビューを提供します。--マーティン・ファウラー

正式な定義とは別に、リポジトリはオブジェクトを格納および取得する方法を知っています。これを実現するには、永続化メカニズム、または少なくともその下にあるデータ アクセス レイヤーについて知る必要があります。

一方、ドメイン モデルは外部のものに依存すべきではありません。Ports and Adaptersアーキテクチャ (従来のレイヤード アプローチよりも DDD に適しています) では、リポジトリはアダプタの 1 つになります。

ドメインはそのリポジトリのインターフェースのみを認識しており、実際の実装は外部にあります。このようにして、内向きの依存関係のみを持ちます。基本的にこれはオブジェクト指向ですが、下向きの依存関係をカスケードする階層化されたアーキテクチャは、より手続き型のアプローチです。

于 2012-11-14T10:53:30.563 に答える
2

アーカイブはユビキタス言語に属するドメインの概念ですか? 存在する場合はArchiveService、ドメイン層で定義する必要があります。それ以外の場合は、インフラストラクチャ レイヤーで定義でき、IRepository の各実装によって、アーカイブするかどうかが選択されます。

ArchiveServiceいずれにせよ、 （または他のサービス）に依存するリポジトリに問題はありません。直後にすべてのコードをrepository.add(entity)呼び出すこともできますが、あまり便利ではありません。archiveService.createVersion(entity)

于 2012-11-14T14:25:45.700 に答える