Подходит ли DDD для приложения, основанного на поиске? - PullRequest
0 голосов
/ 08 ноября 2019

Я изучаю DDD.

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

Пример

Требования: Поиск меню, продаваемого в открытых ресторанах (магазине) в радиусе 2 км. Ввод: местоположение пользователя
Предоставляемый API: API поиска магазина, API открытия магазина (по идентификатору магазина), API меню (по идентификатору магазина)

  1. Выбор списка магазинов из API поиска по местоположению пользователя.
  2. Фильтрсписок магазинов по расстоянию (в пределах 2 км)
  3. Если есть магазины, удовлетворяющие его условиям, извлеките API часов открытых магазинов.
  4. Если есть открытые магазины, извлеките меню из API меню.
  5. Если есть результаты, отсортируйте их по ценам и восстановите все имеющиеся у вас данные.

Вопрос

  1. Я не могуИзвлечь домен / модель в этом случае. что такое сущность домена?

  2. Вот мой пример кода. Но, похоже, это плохо. Я думаю, что SearchMenuService это служба приложений (не служба домена), но есть много логики. Как я могу исправить пример кода?

  3. Если я хочу получить больше данных из остальных API в сущности домена, возможно ли это? Я думаю, что JPA может получить больше данных путем ленивой загрузки.

@Service
public class SearchMenuService {
    private StoreRepository storeRepository;
    private OpenTimeRepository openTimeRepository;
    private MenuRepository menuRepository;

    @Transactional(readOnly = true)
    public ResultMenu getMenus(String location) {
        List<Store> stores = storeRepository.findStore(location);
        List<Store> nearStores = stores.stream().filter(store -> store.distance < 2000).collect(Collectors.toList());
        if (CollectionUtils.isEmpty(nearStores)) {
            throw new NotFoundStoreException();
        }
        List<OpenTime> openTimes = openTimeRepository.findByStores(nearStores);
        List<Store> openStores = new ArrayList<>()
        for (int i = 0; i < nearStores.size(); i++) {
            LocalTime now = LocalTime.now();
            if (openTimes[i].open.isBefore(now) && openTimes[i].close.isAfter(now)) {
                openStores.add(nearStores[i])
            }
        }
        if (CollectionUtils.isEmpty(openStores)) {
            throw new NoOpenStoreException();
        }
        List<Menu> menus = menuRepository.findByStores(openStores)
                .stream()
                .sorted()
                .map(menu -> Pair.of(menu.storeName, menu))
                .collect(Collectors.toList());

        return new ResultMenu(menus);
    }
}

Разве DDD не подходит для этого приложения? Я новичок в DDD. Спасибо за вашу помощь.

1 Ответ

3 голосов
/ 08 ноября 2019

Доменный дизайн хорошо подходит для сложных доменов. Более простое приложение для захвата домена или данных может не подойти. Если у вас есть сложные бизнес-правила, четко определенный домен может предоставить пробег, который вам нужен. Поиск отображаемых данных не совсем вписывается в модель домена, так как домен в большей степени связан со стороной транзакции / записи / изменения состояния вещей.

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

...