Могут ли сервисы вызывать другие сервисы в доменно-управляемом дизайне?

Question

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

Я вижу несколько альтернатив:

1. Это хорошо делать, так как вы повторно используете код.

2. Службы должны иметь доступ к своимсобственный репо для извлечения данных для своих операций

3. Сервисы должны быть изолированы друг от друга и относиться только к одному домену.В моем примере у меня должен быть другой слой, возможно ViewFactory, для вызова служб для извлечения соответствующих данных

Каковы общепринятые нормы в этом вопросе?

Answer 1

Ваш вопрос о доменных службах , а не о службах приложений или инфраструктуры?Если это так, у DDD нет конкретных рекомендаций по изоляции доменных служб друг от друга.Используйте свое суждение и следите за нарушениями SOLID .Также имейте в виду, что доменные сервисы часто используются не по назначению, и имеет смысл использовать больше логики в сущностях :

СЛУЖБЫ должны использоваться разумно и не позволять лишать СУЩНОСТИ и ЗНАЧЕНИЕОБЪЕКТЫ всего их поведения.

Answer 2

Вы можете ... если это соответствует вашему конкретному контексту домена и особенно вашим вариантам использования.

Если у вас есть несколько вариантов использования, которые могут охватывать несколько совокупных корней и их служб, вы можете использовать внутреннюю службу приложений или Domain EventHandler для сохранения принципа DRY без изменений.

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

Мой опыт показывает, что детализация методов обслуживания сильно различается. Если ваши службы работают только с одним (или несколькими) репозиториями, я предполагаю, что ваша гранулярность в порядке - это означает, что у вас есть SaveOrder, LoadOrder, DeleteOrder, LoadUser и т. Д. ...

Большая гранулярность больше ориентирована на прецеденты и пытается сопоставить прецедент с методом обслуживания (или двумя). Но у OrderService могут быть такие методы, как GetUserPurchaseHistory ()

Этот метод возвращает продукты с остатком на счете в объекте DTO ответа. Если вы не хотите использовать DTO, вам, вероятно, понадобятся два сервисных вызова, два из которых возвращают продукты и баланс учетной записи пользователя. НО Помните, что основная задача прикладного уровня обслуживания состоит в том, чтобы обслуживать клиент приложения и его потребности. Если вы не осмеливаетесь сделать свою гранулярность большой, вы можете вытолкнуть логику домена на code-behind / controller / Presenter / webservices. Затем вы принуждали своих клиентов вызывать методы вызова приложений в правильном порядке.

В некоторых проектах я успешно использовал объекты DTO в сложном диалоге, который требует данных, охватывающих несколько агрегатов. Это облегчит работу с ребятами с графическим интерфейсом, а сервисный API более ориентирован на процесс. И да ... Я добавляю несколько репозиториев, которые мне нужны, в ctor для моих сервисов. У меня есть несколько служб, которые совместно используют репозитории (нет строгих отношений 1: 1). Для менее сложного варианта использования я не использую DTO. DTO дает вам накладные расходы и затраты времени и сложности при обслуживании приложений. Хотя он может обеспечить антикоррозионный слой, но очень редко вы получаете это преимущество обратно.

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