干净的架构和存储库

Question

最近，对于我一直在从事的 Flutter 项目，我决定采用使用 Clean Architecture 的功能驱动架构。软件设计非常细致，非常适合逻辑划分。

然而，这些天我出现了一个关于存储库的使用的问题。在使用 Firestore 的应用程序中，存储库是我与此类数据交互的层，在不同功能上对它们进行划分，同时仍处理相同的集合是否正确？ （不同的部分由不同的特征组成，但涉及相同的数据集合）。 在工作结束时，我可能会发现几个具有相同代码的存储库类，即使它们属于不同的功能。

如有澄清，我们将不胜感激！预先感谢

Answer 1

存储库是从外部数据源检索/管理数据的绝佳模型。

该模型是面向实体的。也许这就是促使你问这个问题的原因。 我认为功能驱动设计并不意味着一切都以功能为导向。 我的意思是这个设计决定了你的领域层分类，但不是一切。 仅仅因为每个功能有一个处理程序并不意味着您必须多次重新编码存储库。 存储库是基础设施层的一部分。如果您的应用程序有多个域，它的接口可以由多个项目/模块共享。

在域图层的某个位置（在要素类管理器中），您将使用存储库来加载一些数据。 您需要确保的是您使用接口并且不依赖于存储库实现（也许您已经很清楚了，这只是其他读者的一个观点）。

例如，您可以在 OrderReservationHandler 中使用 IClientRepository 来加载客户数据。

无论你使用哪种设计，你都会面临的困难是：

• 这个存储库将返回什么结果？
• 我应该只加载实体本身还是它的关系？

针对第一点，有以下几种方式：

• 第一个也是我最喜欢的是返回一个 DTO 对象（仅包含属性，没有方法的类）。如有必要，将这些类转换为领域模型（领域层下的类）。
• 第二种：有些开发者更喜欢直接返回Domain Model，以减少数据映射。

对于第二点，我认为无论使用什么设计，它总是相同的难度：

• 我应该加载实体及其关联实体吗？
• 我应该只加载关联实体的标识符并进行延迟加载吗？
• 我可以加载实体聚合（任意连接）以减少数据加载时间并使事情变得更简单吗？

我的观点是，这取决于上下文。 设计是用来让事情变得简单，而不是让事情复杂化。 如果我在系统中完全使用存储库模型，并面临使用许多过滤器进行数据搜索的屏幕实现，我将 随意使用自定义查询或存储过程来加载聚合数据，我不会因为模型而使实现复杂化或使加载变得非常慢。 我认为这里非常重要的一点是知道何时打破规则。没有一个模型可以解决所有问题。 此外，模型通常只能解决一个问题。

结论，在软件项目中我们始终需要：

• 实体完全加载=>慢速模式
• 加载没有关联数据的实体（仅关系标识符）=>快速模式
• 自定义数据加载（任意连接）=>自定义模式

好的设计将帮助您轻松区分这 3 种用途。