Разработка домена Driven Design - где мы должны размещать репозитории?

Question

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

Предположим, у меня будет класс Customer, где вы на самом деле сохраняете объект клиента или агрегированный корень?

Должен ли он быть классом клиента, обладающим знаниями о настойчивости?

var myCustomer = CustomerFactory.CreateCustomer(id); 
myCustomer.Name = ... 
myCustomer.LastName = ... 

myCustomer.Save() 

в этом случае мне нужно будет передать мое хранилище клиентов в класс клиента (либо через завод или какой-либо инъекции). Заметьте, что я не смог найти хороший пример этого в книге DDD Эрика Эвенса.

Другой способ держит клиента бесплатно знать о настойчивости

var myCustomer = CustomerFactory.CreateCustomer(id); 
myCustomer.Name = ... 
myCustomer.LastName = ... 

CustomerRepository repository = new CustomerRepository(); 
repository.Save(myCustomer); 

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

AddCustomerService service = new AddCustomerService(CustomerRepository repository) 
service.AddCustomer(myCustomer); 

просто записочку : Если я действительно не сохраняю в классе клиента, я считаю, что мой класс клиента - это ничего, кроме свойств, возможно, с небольшой проверкой, но не более того. Никакого реального поведения нет. Поведение переносится либо на класс обслуживания, либо на репозитарии, используемые клиентом ...

Answer 1

У меня есть проект DDD. В этом порядке есть 4 слоя (потому что я не использую WCF, иначе их будет больше):

1. UI 
1.1 MVC4.csproj 
... (Repository Interfaces) 
... (Repository Implementations) 

2. Service Layer 
2.1 Service.cs 
...DTOs 

3. Business Layer 
3.1 DomainObjects.csproj 

4. Data Access Layer 
4.1 DAL.csproj (Entity framework 5) 
... (Repository Interfaces) 
... (Repository Implementations 

Answer 2

Последнее предпочтительнее. То есть напишите свой метод сохранения в классе CustomerRepository. В DDD-объектах не должно быть логики устойчивости. Обычно ваши объекты домена не содержат поведения и содержат только свойства (хотя иногда они должны содержать оба).