Можно ли использовать чистый DDD-подход с NHibernate?

Я ' Я немного читал о DDD, и меня смущает, как это вписывается при использовании ORM, такого как NHibernate.

Прямо сейчас у меня есть приложение .NET MVC с довольно «жирными» контроллерами, и я пытаюсь чтобы выяснить, как лучше это исправить. Перемещение этой бизнес-логики на уровень модели было бы лучшим способом сделать это, но я не уверен, как это сделать.

Мое приложение настроено так, что сеанс NHibernate управляется HttpModule (получает сеанс / транзакцию по-моему), который используется репозиториями, которые возвращают объекты сущностей (Think S # arp arch ... оказывается, действительно дублировал большую часть их функций в этом). Эти репозитории используются DataServices, которые сейчас являются просто оболочками вокруг репозиториев (взаимно однозначное сопоставление между ними, например, UserDataService принимает UserRepository, или на самом деле репозиторий). Эти DataServices прямо сейчас только гарантируют, что аннотации данных, украшающие классы сущностей, проверяются при сохранении / обновлении.

Таким образом, мои сущности на самом деле являются просто объектами данных, но не содержат никакой реальной логики. Хотя я мог бы поместить некоторые вещи в классы сущностей (например, метод «Утвердить»), когда это действие должно сделать что-то вроде отправки электронного письма или касания других несвязанных объектов, или, например, проверки, чтобы увидеть, есть пользователи, у которых есть тот же адрес электронной почты до утверждения и т. д., тогда объекту потребуется доступ к другим репозиториям и т. д. Внедрение их с помощью IoC не будет работать с NHibernate, поэтому вам придется использовать фабрику pattern Я предполагаю получить это. Я не понимаю, как бы вы издевались над ними в тестах.

Итак, следующий наиболее логичный способ сделать это, Я бы подумал, что, по сути, было бы иметь службу для каждого контроллера и извлекать всю работу, выполняемую в контроллере в настоящее время, в методы каждой службы. Я бы подумал, что это противоречит идее DDD, поскольку логика теперь больше не содержится в реальных объектах модели.

Другой способ взглянуть на это, я полагаю, состоит в том, что каждая из этих служб формирует единую модель с объект данных, с которым он работает (разделение полей хранения данных и логики, которая работает с ним), но я просто хотел посмотреть, что делают другие, чтобы решить проблему «толстого контроллера» с DDD при использовании ORM, такого как NHibernate, который работает путем возврата заполненных объектов данных и модели репозитория.

Обновлено и извлеките всю работу, выполняемую в данный момент в контроллере, в методы каждой службы. Я бы подумал, что это противоречит идее DDD, поскольку логика теперь больше не содержится в реальных объектах модели.

Другой способ взглянуть на это, я полагаю, состоит в том, что каждая из этих служб формирует единую модель с объект данных, с которым он работает (разделение полей хранения данных и логики, которая работает с ним), но я просто хотел посмотреть, что делают другие, чтобы решить проблему «толстого контроллера» с DDD при использовании ORM, такого как NHibernate, который работает путем возврата заполненных объектов данных и модели репозитория.

Обновлено и извлеките всю работу, выполняемую в данный момент в контроллере, в методы каждой службы. Я бы подумал, что это противоречит идее DDD, поскольку логика теперь больше не содержится в реальных объектах модели.

Другой способ взглянуть на это, я полагаю, состоит в том, что каждая из этих служб формирует единую модель с объект данных, с которым он работает (разделение полей хранения данных и логики, которая работает с ним), но я просто хотел посмотреть, что делают другие, чтобы решить проблему «толстого контроллера» с DDD при использовании ORM, такого как NHibernate, который работает путем возврата заполненных объектов данных и модели репозитория.

Обновлено Думаю, моя проблема в том, как я смотрю на это: NHibernate, кажется, помещает бизнес-объекты (сущности) в нижнюю часть стека, на которые затем действуют репозитории. Репозитории используются службами, которые могут использовать несколько репозиториев и другие службы (электронная почта, доступ к файлам) для выполнения действий. Т.е.: Приложение> Службы> Репозитории> Бизнес-объекты

Чистый подход DDD, о котором я читаю, похоже, отражает предвзятость Active Record, когда функции CRUD существуют в бизнес-объектах (это я вызываю User.Delete напрямую вместо Repository .Delete из службы), а фактический бизнес-объект обрабатывает логику вещей, которые должны быть выполнены в этом экземпляре (например, отправка электронной почты пользователю, удаление файлов, принадлежащих пользователю, и т. Д.). Т.е. Приложение> (Службы)> Бизнес-объекты> Репозитории

С NHibernate, кажется, мне было бы лучше использовать первый подход, учитывая то, как работает NHibernate, и я ищу подтверждения своей логики. Или, если я просто запутался, некоторые пояснения относительно того, как должен работать этот многоуровневый подход. Я понимаю, что если у меня есть метод «Утвердить», который обновляет модель пользователя, сохраняет ее и, скажем, отправляет электронное письмо нескольким людям, этот метод должен применяться к объекту сущности пользователя, но для обеспечения надлежащего IoC, чтобы я мог внедрить MessagingService, мне нужно сделать это на уровне моего сервиса, а не в объекте User.

С точки зрения "множественного пользовательского интерфейса" это имеет смысл, поскольку логика выполнения действий берется из моего уровня пользовательского интерфейса (MVC) и помещается в эти службы ... но я, по сути, просто учитываю логику в другой класс вместо того, чтобы делать это непосредственно в контроллере, и если у меня никогда не будет задействован какой-либо другой пользовательский интерфейс, то я просто обменял «толстый контроллер» на «толстую службу», поскольку служба, по сути, будет инкапсулировать метод для каждого действия контроллера для выполнения своей работы.