Итак, наша цель - вызвать сервис (в этом-то и проблема), который может предоставить информацию об основном субъекте (например, Заказ) и всю информацию о связанных с ним субъектах (например, Покупатель), но с ним связана модель Заказа. через свойство с именем BuyerId.
Вы уже знаете, что какой-то компонент должен отвечать за агрегирование данных. Обычно это сводится к решению, будет ли агрегация происходить в нисходящем направлении (например, в пользовательском интерфейсе) или в восходящем направлении (например, на сервере).
Если API уже существуют для сбора данных Покупателя и данных Заказа, и у нижестоящего клиента имеются необходимые идентификаторы корреляции, то для последующего клиента становится возможным справиться со сложностью агрегирования данных. Приемлемо это или нет - другая история.
Если вы хотите решить проблемы с агрегацией данных в восходящем потоке, скорее всего, у вас будет две основные стратегии на выбор:
Агрегат в заявке
public OrderDetailsDto orderDetails(OrderId orderId) {
//Repositories could be switched to remote API calls
Order order = orderRepository.findById(orderId);
Buyer buyer = buyerRepository.findById(order.buyerId);
return dtoAssembler.orderDetailsFrom(order, buyer);
}
Агрегат в базе данных
public OrderDetailsDto orderDetails(OrderId orderId) {
ResultSet resultSet = orderDetailsFromDb(orderId);
return dtoAssembler.orderDetailsFrom(resultSet);
}
Возможно, нам нужно использовать DTO
Как видите, обе реализации могут возвращать один и тот же DTO. Использование явных DTO - очень полезный и популярный подход для решения проблем контрактов и сериализации. Как данные отображаются в таких DTO полностью зависит от вас, и существует множество стратегий реализации.