Вопросы, связанные с доменным дизайном

Question

После прочтения проекта Eric Evans, управляемого доменом У меня есть несколько вопросов. Я искал, но не нашел, где я мог бы найти удовлетворительные ответы. Пожалуйста, дайте мне знать, если у вас есть четкое понимание ниже вопросов.

Мои опасения

1. Repository для получения уже существующих агрегатов из БД, веб-службы. Если да, Can Repository также имеет транзакционные вызовы для этого объекта (т. Е. Сумму перевода, отправку сведений о счете ... и т. Д.)

2. Может ли организация иметь методы, которые имеют бизнес-логику, в которой она вызывает инфраструктуру. Службы уровня для отправки писем. . logs и т. д. (методы Entity, вызывающие службы IS direclty).

3. Реализация хранилища и фабричные классы будут находиться в Уровне Инфраструктуры. это правильное утверждение?

4. Может ли пользовательский интерфейс (контроллер) напрямую использовать методы репозиториев? или следует назвать их из уровня приложения?

Есть еще много много путаницы в моем уме ... пожалуйста, руководство меня ... книги я использую домен управляемого DESING Eric Эвана ...... .NET Домен-Driven Design с C#

Answer 1

1. Существует много споров о том, должны ли репозитории быть только для чтения или разрешать транзакции. DDD не диктует ни одно из этих представлений. Вы можете сделать то и другое. Сторонники репозиториев только для чтения предпочитают Единицу работы для всех операций CUD.

2. Большинство людей (включая себя) считают хорошей практикой, что сущности являются постоянными-невежественными. Расширение этого принципа немного указывает на то, что они должны быть автономными и свободными от всех служб уровня инфраструктуры - даже в абстрактной форме. Поэтому я бы сказал, что вызовы служб инфраструктуры относятся к классам Service, которые работают с Entities.

3. Звучит правильно, что реализации Репозитория и Фабрики (если они есть) должны находиться на уровне инфраструктуры. Однако их интерфейсы должны находиться в доменном слое, чтобы службы домена могли взаимодействовать с ними, не завися от уровня инфраструктуры.

4. DDD действительно не диктует, можете ли вы пропустить слои или нет. В конце книги Эванс немного рассказывает о расслоении и называет его Relaxed Layering, когда вы разрешаете это, поэтому я думаю, что он просто рассматривает его как один из вариантов среди нескольких. Лично я предпочел бы предотвратить пропуски слоя, потому что это облегчает ввод некоторых действий в будущем, если вызовы уже проходят через правильные слои.

Answer 2

1. Лично в моем последнем DDD-проекта, я использую единицы работы, которая держит сессию NHibernate. UoW вводится в хранилищах, предоставляя им единственную ответственность за добавление, удаление и поиск.

2. Эванс заявил, что одна часть головоломки, которая отсутствует в книге DDD, - «События домена». Использование чего-то вроде Udi Dahan's DomainEvents даст вам полностью развязанную архитектуру (объект домена просто вызывает событие).Лично я использую модифицированную версию событий домена и StructureMap для проводки. Он отлично работает для моих нужд.

3. Я рекомендую на основе других рекомендаций, чтобы интерфейсы репозитория были частью модели, а их реализации были частью инфраструктуры.

4. Да! Я лично работал над тремя веб-проектами DDD, где сервисы и репозитории были введены ведущим/контроллерам (ASP.NET/ASP.NET MVC), и это имело большой смысл в нашем контексте.

Answer 3

1. Хранилище должно быть только для поиска и сохранения объектов, не должно быть какой-либо бизнес-логики в этом слое. Например:

   репозиторий.TransferAmount (сумма, toAccount); // это плохо

2. Сущности могут делать такие вещи, как отправлять электронные письма, если они зависят от абстракций, определенных в вашем домене. Реализация должна быть в вашем инфраструктурном слое.

3. Да, вы разместили реализацию своего хранилища на своем инфраструктурном уровне.

4. Может ли пользовательский интерфейс (контроллер) напрямую использовать методы репозиториев? или следует назвать их из уровня приложения?

Да, я стараюсь следовать этому образцу, по большей части:

[UnitOfWork] 
public ActionResult MyControllerAction(int id) 
{ 
    var entity = repository.FindById(id); 
    entity.DoSomeBusinessLogic(); 
    repository.Update(entity); 
}