Доступ к библиотекам классов проектирования, управляемых доменом, из службы WCF

Мне нужна помощь в разъяснении того, как я должен настраивать свой проект. Моя структура решения выглядит следующим образом:

Company.DataTransferObjects
--AdminDTO.cs
--CustomerDTO.cs
Company.DataTransferObjects.Helpers
Company.Infrastructure.DomainServices
--Admin
---AdminService.cs
--Customer
--CustomerService.cs
Comapny.Infrastructure.Repositories
--Admin
---AdminRepository.cs
--Customer
---CustomerRepository.cs
Company.Domain
--Admin
---Admin.cs
---IAdminRepository.cs
--Customer
---Customer.cs
---ICustomerRepository.cs
Company.WebServices
--WebApi.cs
--IWebAPI.cs

Мои вопросы заключаются в следующем:

1) Подходит ли вам моя установка?

2) ДТО. С точки зрения веб-службы, где следует создавать DTO? Должен ли я создавать DTO в независимой библиотеке классов и ссылаться на них из WebService или они должны быть частью моего проекта веб-сервиса?

Кроме того, мне непонятно, как мои DTO должны взаимодействовать с объектами домена. Может кто-нибудь объяснить их цель с точки зрения потока программы и, в частности, если бы вы создавали службу WCF, как бы вы манипулировали ими?

3) Доменные службы. Мне все еще трудно понять назначение доменных служб. Это то, что раскрывает операционную функциональность, которая не затрагивает базу данных и требует методов репозитория, к которым нельзя получить прямой доступ? Другими словами, является ли доменная служба методом, который манипулирует несколькими методами репозитория? Итак, если моя служба WCF вызывает данные, к которым можно получить доступ через метод репозитория, то это то, что она должна делать. Но если для этого требуются данные, которые являются результатом нескольких методов репозитория, то это должно быть сделано через службы домена?

4) Какое место шаблон фасада занимает в архитектуре DDD?

Пожалуйста, извините мою путаницу, я пытаюсь понять. Было бы серьезной помощью, если бы вы могли сказать мне, «к чему» я должен получить доступ из моей службы WCF.

Спасибо!


repository wcf domain-driven-design
person Peter    schedule 09.01.2011    source источник

Ответы (1)


arrow_upward
0
arrow_downward

идя в обратном порядке на ваши вопросы:

4) Ваши веб-сервисы фактически являются фасадом вашего домена.

3) Доменные службы также могут обращаться к БД, они, как правило, являются основным API, который потребляющий код должен использовать для взаимодействия с вашим доменом во всем, что включает в себя более одного объекта, или для вещей, которые представляют собой серию транзакционных шагов. Некоторые люди считают репозитории частным случаем доменных служб (вместо того, чтобы быть или/или). Обычно я считаю свои службы общедоступным интерфейсом своего домена.

2) DTO обычно полезны, когда вы (или планируете в конечном итоге) пересечь физические границы. Каждый раз, когда вы думаете, что вам может понадобиться что-то сериализовать (например, в сообщение SOAP), вы хотите подумать о DTO. SO в вашем случае ваш проект WCF будет использовать DTO в качестве своих DataContracts, но внутри он может использовать объекты вашего домена (если вы не ожидаете, что ваш домен будет находиться в другом домене приложения или в другом физическом поле).

1) Это все личные предпочтения; ваш макет не выглядит неразумным, хотя он отличается от того, как я обычно организую.

person Paul    schedule 09.01.2011
comment
Спасибо, Пол. Итак, будет ли мой проект WCF ссылаться на мои доменные службы или мой домен (или на оба)? - person Peter; 10.01.2011
comment
Ваши доменные службы (как минимум интерфейсы для них) должны находиться в проекте модели предметной области. Проект WCF должен иметь ссылки на все, что ему нужно, поэтому определенно проект предметной области, возможно, другие проекты, которые также имеют конкретные реализации. - person Paul; 10.01.2011