ファサードとしてのドメインサービス

C＃を使用した.NETドメイン駆動設計：問題-設計-解決策を読んだところ、作成者が各集計ルートのドメインサービスを作成していることに気付きました。

ただし、ドメインサービスは対応するリポジトリのファサードにすぎませんでした。たとえば、これは彼の本のアプリケーションのコードサンプルです。

public static class CompanyService
{
    private static ICompanyRepository repository;
    private static IUnitOfWork unitOfWork;

    static CompanyService()
    {
        CompanyService.unitOfWork = new UnitOfWork();
        CompanyService.repository = 
            RepositoryFactory.GetRepository<ICompanyRepository, 
            Company>(CompanyService.unitOfWork);
    }

    public static IList<Company> GetOwners()
    {
        return CompanyService.GetAllCompanies();
    }

    public static IList<Company> GetAllCompanies()
    {
        return CompanyService.repository.FindAll();
    }

    public static void SaveCompany(Company company)
    {
        CompanyService.repository[company.Key] = company;
        CompanyService.unitOfWork.Commit();
    }

    public static Company GetCompany(object companyKey)
    {
        return CompanyService.repository.FindBy(companyKey);
    }
}

ご覧のとおり、サービスへのほとんどすべての呼び出しは、リポジトリ呼び出しのラッパーです。ドメインサービスを構築する場合、これは良いパターンですか？

リポジトリを常にドメインサービスにラップする必要がありますか？より良いアプローチはありますか？

リポジトリは、データストアの抽象化を目的としており、一般にデータ取得機能を提供します。この配置により、たとえば、データストアをいくつかの異なるデータストアに変更できます（たとえば、実際にはほとんど発生しませんが、OracleからSQL Serverに変更）。実装固有の詳細。

一方、サービスレイヤーは、外部のユーザーまたはエージェントが使用することを目的としたAPIであり、データの取得自体ではなく、サービスを提供します（それは可能です）。Service APIは複数のリポジトリーを利用し、クライアントに提供する前にデータを変換する場合があります。データをカスタムオブジェクトにラップしたり、ページング機能を提供したりできます。単純なデータの保存と取得以外にも、サービスレイヤーでさまざまなことができます。

リポジトリが提供する以上の追加の抽象化レイヤーを提供する必要がない場合は、サービスレイヤーはまったく必要ない可能性があります。

アプリケーションが成長するにつれて、サービス層がラップして公開できる複雑な操作があります。これは、実際にはドメインモデルのファサードです。たとえば、販売アプリでは、モデル内の個別のオブジェクトとしてラインアイテムを気にする必要がない場合があります。カートにアイテムを追加してチェックアウトし、割引が適用された後にユーザーの請求書を印刷したいだけです。

舞台裏には、おそらく何十ものオブジェクトが相互作用に関与しています。サービスは、オブジェクトモデルの平坦化されたビューを投影する場合があります。これにより、ドメインモデルがバックグラウンドで変更されても、クライアントはそれらの変更の影響を受けません。