DDD 是否适合基于搜索的应用程序?

Is DDD good for a search based application?

我正在学习 DDD。

但我不知道如何在我的应用程序中应用 DDD。 我几乎所有的应用程序都有简单的要求。 只需从 API 获取数据并重组它们。如果需要的数据较多,则调用 more API.

例子

要求:搜索半径2公里内已开业餐厅(商店)出售的菜单 输入:用户的位置
提供 API:搜索商店 API、商店营业时间 API(按商店 ID)、菜单 API(按商店 ID)

  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 的初学者。 感谢您的帮助。

领域驱动设计非常适合复杂的领域。更简单的域或数据捕获应用程序可能不太适合。如果您有复杂的业务规则,一个定义明确的域可能会提供人们所追求的里程。搜索要显示的数据不太适合域模型,因为域更关心事物的 transactional/write/changing 状态方面。

查询通常不会使用域对象。不应查询聚合,因为它们很可能包含比所需数据多得多的数据,并且数据可能被封装到相关位可能不可用的程度。查询层可能更适合您更接近原始数据的地方。在某些情况下,您可能会使用 read models 但这些是没有域行为的简单数据传输对象。这并不意味着您不能使用诸如规范之类的东西,但这些更多是技术问题而不是业务问题。