Serviços de domínio como fachadas

Li o .NET-Driven Design com C #: Problem - Design - Solution e notei que o autor criou um serviço de domínio para cada raiz agregada.

No entanto, os serviços de domínio eram apenas fachadas para o repositório correspondente. Por exemplo, este é um exemplo de código do aplicativo de seu livro

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);
    }
}

Como você vê, quase todas as chamadas para os serviços são wrappers para chamadas de repositório. Esse é um bom padrão ao criar serviços de domínio?

Devemos sempre envolver nossos repositórios em serviços de domínio? Existe uma abordagem melhor?

Um repositório deve ser uma abstração para seu armazenamento de dados e geralmente fornece recursos de recuperação de dados. Esse arranjo permite, por exemplo, alterar o armazenamento de dados para algum armazenamento de dados diferente (por exemplo, do Oracle para o SQL Server, embora na prática isso raramente aconteça), e a API do repositório ainda funcionará, se você não expôs nenhum detalhes específicos da implementação.

Uma camada de serviço, por outro lado, é uma API destinada a ser consumida por algum usuário ou agente externo e fornece serviços , não a recuperação de dados em si (embora possa fazer isso). Uma API de serviço pode desenhar em vários repositórios e executar transformações nos dados antes de servi-los ao cliente. Pode agrupar os dados em objetos personalizados ou fornecer recursos de paginação. Você pode fazer coisas em sua camada de serviço além do simples armazenamento e recuperação de dados.

Se você não precisar fornecer uma camada adicional de abstração além do que o seu Repositório fornece, talvez não precise de uma Camada de Serviço.

À medida que seu aplicativo cresce, há operações complexas que sua camada de serviço pode quebrar e expor. É realmente uma fachada sobre o modelo de domínio. Por exemplo, em um aplicativo de vendas, você pode não se importar com o item de linha como um objeto discreto no modelo. Você só deseja adicionar itens a um carrinho, fazer check-out e imprimir uma fatura para o usuário após a aplicação de descontos.

Nos bastidores, provavelmente existem dezenas de objetos envolvidos na interação. O serviço pode projetar uma visualização nivelada do modelo de objeto para que, à medida que o modelo de domínio seja alterado nos bastidores, o cliente não seja impactado por essas alterações.