У меня проблема с агрегатом, который со временем будет увеличиваться. Однажды появятся тысячи записей, и оптимизация будет плохой.
@Entity
public class Serviceman ... {
@ManyToMany(mappedBy = "servicemanList")
private List<ServiceJob> services = new ArrayList<>();
...
public Optional<ServiceJob> firstServiceJobAfterDate(LocalDateTime dateTime) {
return services.stream().filter(i -> i.getStartDate().isAfter(dateTime))
.min(Comparator.comparing(ServiceJob::getStartDate));
}
}
Метод просто загружает все ServiceJob, чтобы получить только одно из них. Возможно, мне следует делегировать этот метод службе с собственным sql.
Вы должны проектировать маленькие агрегаты вместо больших.
В этом эссе подробно объясняется, как это сделать: http://dddcommunity.org/library/vernon_2011/. В нем объясняется, как разложить ваши агрегаты на более мелкие, чтобы вы могли справиться со сложностью.
В вашем случае вместо агрегата, состоящего из двух объектов: Мастер по ремонту и Сервисная работа, где Мастер по ремонту является корнем агрегата, вы можете разложить его на два меньших агрегата с одним объектом. ServiceJob будет ссылаться на Serviceman по идентификатору, и вы можете использовать ServicejobRpository для выполнения запросов.
В вашем примере у вас будет ServicejobRpository.firstServiceJobAfterDate (идентификатор guid servicemanID, дата DateTime).
Таким образом, если у вас много сущностей и вам нужно масштабироваться, вы можете хранить сущности Servicejob на другом сервере БД.
Если по какой-то причине Мастер по ремонту или Сервисная работа нуждаются в ссылках друг на друга для выполнения своей работы, вы можете использовать Оказание услуг, который будет использовать ВоеннослужащийХранилище и ServicejobRepository для получения обоих агрегатов и передачи их друг другу, чтобы они могли выполнять свою работу.