尽管您的问题主要是基于意见的，但我可以为您提供一些想法，为什么 ngrx 是一个不错的选择。尽管人们说将所有应用程序状态放在一个对象（单一状态树）中并不是一个好主意。但是，在我看来，无论如何，您的状态都会存在。有了一个商店，它就在一个地方，突变是明确的和跟踪的，而不是到处乱扔的，并由组件在本地维护。此外，您可以从应用程序中的商店中选择特定属性，因此您只能选择您关心的数据。如果您通过始终返回一个数组并使用 Observables 在您的 reducer 中实现不变性，您可以使用 ChangeDetectionStrategy OnPush。 OnPush 给你一个很好的性能提升。我们来看看下图取自Angular官方docs：
如您所见，Angular 应用程序是使用组件架构构建的，这导致了组件树。组件上的OnPush 意味着只有当输入属性发生更改时，才会启动更改检测。例如，如果Child B 是OnPush 并且Child A 是Default，并且您更改了Child A、@987654342 内部的某些内容@ 的变化检测器不会被触发，因为没有输入属性发生变化。但是，如果您更改 Child B 内部的某些内容，Child A 将被重新渲染，因为它具有默认的更改检测器。
关于性能和单一状态树的内容太多了。存储的另一个优点是您可以实际推断您的代码和状态更改。所以大多数 Angular 1.x 应用程序的现实是范围汤。这是来自 Lukas Ruebbelke 的 blog post 的精美图片：
图片显示它非常好。来自 Tero Parviainen 的另一位 article 谈到了他如何通过禁止 ng-controller 来改进他的 Angular 应用程序。这一切都与范围汤有关，管理不断变化的状态是一件困难的事。 redux 动机表示以下see here：
如果一个模型可以更新另一个模型，那么一个视图可以更新一个模型，
这会更新另一个模型，而这反过来可能会导致另一个模型
查看更新。在某些时候，你不再明白会发生什么
在您的应用程序中，因为您无法控制何时、为什么以及如何
它的状态。当系统不透明且不确定时，很难
重现错误或添加新功能。
通过使用ngrx/store，您实际上可以解决这个问题，因为您将在您的应用中获得清晰的数据流。
由于ngrx 受到redux 的高度启发，我想说同样的main principles 应用：
因此，在我看来，最大的好处是您能够轻松跟踪用户交互和状态变化的原因，因为您调度操作并且这些操作总是指向一个位置，而对于普通模型，您必须找到所有引用并查看更改内容和时间。
使用 ngrx/store 还可以让您使用 devtools 来查看调试状态容器并恢复更改。我想，时间旅行是 redux 的主要原因之一，如果你使用的是普通的旧模型，那是相当困难的。
@muetzerich 已经提到的可测试性也是使用 ngrx/store 的一个好处。 Reducers 是纯函数，这些函数很容易测试，因为它们接受输入并简单地返回输出，并且不依赖于函数外部的属性并且没有副作用，例如http 调用等
要跳到底线，我想说不需要使用 ngrx/store 来做任何这些事情，但你会受到限制（上面提到的三个原则），它提供了一个通用模式和带来不错的好处。
对于您的问题：
如果我有多种数据类型（库存、订单、客户...），我的应用是否需要多个商店？
不，我不建议使用多个商店。
如何构建（设计）我的应用程序以处理此类多种数据类型？
也许 Tero Parviainen 的 blog post 可以帮助您弄清楚如何设计您的商店。他解释了如何为示例应用设计应用状态树。