DDD: репозитории, вызывающие Application Services

Это часть серии, основанной на том, как я разбираюсь в DDD :)

Следуя предыдущему вопросу, но фоновые знания не требуются: databases-have">Система, использующая службы WCF из другой системы, когда базовые базы данных имеют отношения

Есть система документов и система управления персоналом. Системе управления персоналом необходимо сохранить документ, а также некоторые специфические для отдела кадров данные, относящиеся к документу.

Моя первая мысль заключалась в том, что вызов Document System должен быть в службе приложений системы управления персоналом (удален ненужный код):

public class HRDocumentService
{
    public void SaveDocument(string filename, string employee)
    {
        long documentLibraryId = _documentLibraryService.SaveDocument(filename);
        HRDocument hrDocument = HRDocument.CreateDocument(documentLibraryId, employee);
        _hrDocumentRepository.Save(hrDocument);
    }
}

а репозиторий такой:

public class HRDocumentRepository
{
    public long Save(HRDocument hrDocument)
    {
        _session.Save(hrDocument);
    }
}

Но Джек Чарльтон говорит в этой статье "Что скрывается за репозиторием? Почти все, что вам нравится. Да, вы не ослышались. У вас может быть база данных или у вас может быть много разных баз данных. Вы можете использовать реляционные базы данных или объектные базы данных. база данных в памяти или синглтон, содержащий список элементов в памяти. У вас может быть уровень REST, или набор сервисов SOA, или файловая система, или кеш в памяти…»

Итак, теперь я думаю, что сервис должен быть таким:

public class HRDocumentService
{
    public void SaveDocument(string filename, string employee)
    {
        HRDocument hrDocument = HRDocument.CreateDocument(documentLibraryId, employee);
        _hrDocumentRepository.Save(hrDocument);
    }
}

и вызывает службу библиотеки документов в репозитории следующим образом:

public class HRDocumentRepository
{
    public long Save(HRDocument hrDocument)
    {
        long documentLibraryId = _documentLibraryService.SaveDocument(filename);
        hrDocument.DocumentLibraryId = documentLibraryId;
        _session.Save(hrDocument);
    }
}

Таким образом, возможно, репозиторий по-прежнему отвечает только за сохранение.

Я на правильном пути здесь или далеко?


person Paul T Davies    schedule 06.07.2011    source источник


Ответы (2)


Кажется, что доступ репозиториев к службам приложений из других систем является вполне принятой практикой. Руководство по архитектуре приложений Microsoft поддерживает это в форме "службы Агент», и приведенная выше цитата Джека Чарльтона также подтверждает это. Если вы используете NHibernate для доступа к данным, вы можете сделать это, реализовав IUserType, как я упоминаю в этом сообщении: NHibernate: отложенная загрузка IUserType. Это не универсальное решение — например, оно имеет низкую производительность, если вы возвращаете коллекцию, и каждый объект должен выполнять вызов WCF для своего дочернего объекта. Спрашивая об интеграции систем, люди часто выступают за обмен сообщениями и CQRS, но даже сам Уди Дахан утверждает, что это не подходит для подавляющего большинства систем.

person Paul T Davies    schedule 03.09.2011

Доменные службы находятся перед репозиториями и сущностями, поэтому использование DocumentLibraryService внутри HRDocumentRepository не соответствует DDD.

Ваша первая мысль была правильной!

Но сама логика (присвоение некоторого значения объекту перед сохранением) вполне допустима внутри репозитория, если вы можете получить информацию не из службы, а из репозитория.

Надеюсь это поможет.

Роберт

person rObiwahn    schedule 07.07.2011