Домен управляемый дизайн запутан

Question

1) Что такое BLL-services? В чем разница между ними и услугами Service Layer? Что входит в службы домена и что идет на уровень обслуживания?

2) Howcome I реорганизовать BBL модель, чтобы дать ему поведение: Post объекта содержит коллекцию обратных связей, которые уже дают возможность добавить еще Feedback через feedbacks.Add(feedback). Obviosly нет расчетов в простой блог-приложение. Должен ли я определить метод для добавления Feedback внутри объекта Post? Или должно ли это поведение поддерживаться соответствующей службой?

3) Должен ли я использовать Unit-Of-Work (и UnitOfWork-Repositories) образец, как это описано в http://www.amazon.com/Professional-ASP-NET-Design-Patterns-Millett/dp/0470292784 или было бы достаточно, чтобы использовать NHibernate ISession?

Answer 1

Вам не нужен блок-оф-работы шаблон сверху на сессии NHibernate:

Why would I use the Unit of Work pattern on top of an NHibernate session?

Using Unit of Work design pattern/NHibernate Sessions in an MVVM WPF

Answer 2

1) Business Layer и Service Layer фактически синонимами. «Официальный» DDD-термин - Application Layer.

Роль Application Layer заключается в координации работы между Domain Services и Domain Model. Это может означать, например, что функция приложения сначала загружает объект через Repository, а затем вызывает метод для объекта, который будет выполнять фактическую работу.

2) Иногда, когда ваше приложение в основном управляется данными, создание полнофункционального Domain Model может показаться излишним. Однако, на мой взгляд, когда вы привыкаете к Domain Model, это единственный способ, которым вы хотите пойти.

В случае Post и Feedback, вы хотите AddFeedback(Feedback) метод с самого начала, так как это приводит к уменьшению сцепления (вы не должны знать, если FeedBack элементы хранятся в List или в Hashtable, например) и он предложит вам хорошую точку расширения. Что делать, если вы хотите добавить чек, чтобы не более 10 Feedback элементов. Если у вас есть метод AddFeedback, вы можете легко добавить чек в одну точку.

3) Образцы UnitOfWork и Repository являются фундаментальной частью DDD. Я не эксперт по NHibernate, но всегда полезно скрывать специфические для инфраструктуры детали интерфейса. Это уменьшит сцепление и улучшит тестируемость.

Answer 3

Предлагаю вам сначала прочитать книгу DDD или its short version, чтобы получить общее представление о строительных блоках DDD. Нет такой вещи, как BLL-Service или Service Service Service. В DDD у вас

• слой (Domain сердце вашего программного обеспечения, где объекты домена проживают)
• прикладном (дирижирует приложение)
• слоя инфраструктуры (настойчивость, отправку сообщения ...)
• Уровень презентации.

Во всех этих слоях могут быть услуги. Служба существует только для обеспечения поведения для ряда других объектов, у нее нет состояния. Например, служба уровня домена - это то место, где вы ставите сплоченное деловое поведение, которое не принадлежит ни одному конкретному домену и/или требуется многим другим объектам. Входы и выходы операций, которые он предоставляет, обычно являются объектами домена.

Во всяком случае, когда операция, кажется, прекрасно вписываются в сущность с точки зрения домена (например, добавление обратной связи к столбу, который переводит в Post.AddFeedback() или Post.Feedbacks.Add()) , Я всегда предпочитаю это, а не добавляю Сервис, который только разбрасывал бы поведение в разных местах и ​​постепенно приводил бы к модели анемичного домена. Могут быть исключения, например, при добавлении обратной связи к сообщению требуется соединение между множеством разных объектов, но это явно не так.