Я делаю свои первые шаги в дизайне, управляемом доменом, купил синюю книгу и все остальное, и я вижу три способа реализации определенного решения. Для записи: я не использую CQRS или Event Sourcing.
Допустим, запрос пользователя поступает на уровень обслуживания приложений. Бизнес-логика для этого запроса (по какой-либо причине) разделена на метод объекта и метод доменной службы. Как я должен идти о вызове этих методов?
Варианты, которые я собрал до сих пор:
- Пусть служба приложения вызовет оба метода
- Используйте инъекцию метода / двойную диспетчеризацию для внедрения доменной службы в сущность, позволяя сущности делать свое дело, а затем позволяя ему вызывать метод доменной службы (или наоборот, позволяя доменной службе вызывать метод для сущности).
- Вызывает событие домена в методе объекта, обработчик которого вызывает службу домена. (Вид доменов, о которых я говорю, это: http://www.udidahan.com/2009/06/14/domain-events-salvation/ )
Я думаю, что все это жизнеспособно, но я не могу выбирать между ними. Я долго думал об этом и дошел до того, что больше не вижу семантических различий между ними. Знаете ли вы о некоторых руководящих принципах, когда использовать что?
Ответы:
Служба приложений, как правило, является отличной отправной точкой для этого, однако вы всегда должны пытаться изменить поведение как можно ближе к сущности. Служба приложения играет оркестрирующую роль и создает условия для выполнения поведения домена и, таким образом, обеспечивает все необходимые зависимости. Однако, когда это возможно, он должен делегировать поведение модели предметной области.
Это лучший подход, потому что большая часть поведения делегируется объекту или доменной службе. Наиболее несвязанный способ реализовать это состоит в том, чтобы объект выражал зависимость от службы в качестве параметра метода, обеспечивающего поведение под рукой.
Паттерн доменных событий, как объясняют Уди, а также сам Эванс, довольно универсален и может применяться в самых разных сценариях. Однако есть несколько осложнений. Во-первых, вы должны убедиться, что у вас есть правильная область видимости в издателе событий домена. В большинстве случаев у обработчиков событий вашего домена будут зависимости, и если вы используете контейнер IoC, вы должны убедиться, что в них вставлены правильные экземпляры. Например, в веб-приложении
[ThreadStatic]Атрибут проблематичен для определения объема. Другая сложность заключается в наличии границ транскрипции. Вы должны принимать во внимание транзакции, потому что если объект вызывает событие домена, но последующая фиксация в базе данных завершается неудачно, всем обработчикам событий домена потребуется способ отката, в противном случае вы в конечном итоге вызовете недопустимое событие. Однако, если у вас есть эти основы, то доменные события являются отличным шаблоном для инкапсуляции логики домена в самих сущностях.Разница между подходом 2 и 3 зависит от варианта использования. Событие домена применяется, когда вы хотите вызвать дополнительное поведение в ответ на событие, которое находится в прошедшем времени . Это важное ограничение, так как обработчик событий домена не может влиять на поведение объекта. С другой стороны, при подходе 2 внедренный сервис потенциально может влиять на поведение, потому что он объявлен зависимостью для этого конкретного поведения.
источник