【问题标题】:How to implement DDD and Repository Design Pattern for a Remote data store and a local one?如何为远程数据存储和本地数据存储实现 DDD 和存储库设计模式?
【发布时间】:2018-04-02 14:06:35
【问题描述】:

我是 DDD 和存储库设计模式的新手,事实上我在这方面没有任何经验。不久前我遇到了它,虽然我不完全理解它,但我觉得它真的很灵活,我应该试一试。所以我正在研究这个新的 Xamarin.Forms 项目,我想实现它。该应用程序涉及从 google firebase 获取数据并将这些数据保存在本地数据库中。现在从我所读到的关于存储库模式的内容中,存储库只是作为实际数据存储的抽象,因此客户端代码不知道数据的持久性和获取是如何完成的,所以这样可以在不破坏客户端代码的情况下更改数据源/存储(如果我错了,请纠正我)。我遇到的第一个问题是如何定义我的模型,我在网上阅读了很多关于如何在 DDD 中定义模型的文章,但他们所做的只是谈论和谈论并没有具体的答案,我的模型定义是否应该镜像我的数据如何存储在 firebase 上,或者我将如何将其保存在本地 sqlite db 上?。 这个问题困扰了我一段时间,然后我意识到这两种方式都是错误的,领域模型应该与如何它是持久化的,除非它是持久化模型,所以我再次上网阅读了域模型和持久性模型,我得到了更多的讨论。底线是,有人可以通过示例简单地向我解释如何将域模型与其持久性模型分开以及如何为两个数据存储设计存储库,我是否会有一个用于本地存储库和另一个用于本地存储库的存储库? firebase 一,那么我何时以及如何使用域和持久性模型?

【问题讨论】:

    标签: firebase-realtime-database domain-driven-design repository-pattern ddd-repositories domain-model


    【解决方案1】:

    在完美世界中,您根本不需要持久性模型。你如何持久化你的领域模型只是一个实现细节,当你首先构建领域模型时你不应该担心它。 当然,在实践中,您不能真正 100% 地遵守这一原则。

    我的模型定义是否应该反映我的数据在 firebase 上的存储方式

    您可能有一个与数据存储具有一对一映射的模型。这就是适合您的持久性模型。通常只是一个贫血的礼包,里面装满了setter和getter。持久性模型的重点在于它只是一个实现细节。您不会将其暴露给用户。您不会从任何存储库中返回它。

    您的存储库的具体实现将创建并使用持久性模型来保存和检索存储中的数据。这是它唯一的责任。只有当您的工具(很可能是 ORM)不允许您这样做时,您才应该这样做。

    此时,您可以:

    1. 将持久性模型封装到域模型中。 您可以在存储库中执行此操作,因为存储库将始终只返回域模型。您的域模型可以处理持久性模型,并将这种复杂性隐藏在客户端之外。

      说实话,我觉得这个解决方案真的很难看,因为域模型必须首先意识到持久性模型。

    2. 从持久性模型映射到域模型。 您需要将持久性中的各个字段/属性映射到域对象。这可能很耗时,因为通常这意味着您需要自己(在存储库中)从持久性模型中创建域模型,反之亦然,但会明确区分域和持久性。

    【讨论】:

    • 谢谢,选项 2 听起来好多了,但我仍然对如何实现这一点有点迷茫。我不介意代码示例。我的 google firebase 数据存储库是否应该与本地 sqlite db 的存储库分开?如果是,那么我将不得不为每个域模型定义两个持久性模型(一个用于 sqlite db,另一个用于 firebase)。我说的对吗?
    【解决方案2】:

    如有错误请指正

    你的基本想法是正确的; Evans 最初将存储库描述为一种提供内存集合错觉的方式。也就是说,客户端不直接与持久化组件对话;它与实现存储库 api 的 something 对话,该实现负责存储的细节。

    底线是,有人可以通过示例简单地向我解释如何将域模型与其持久性模型分开

    这可能有助于重新确认基本动机:我们试图使域模型和持久模型保持不同,因为它们往往会在不同的时间表上发生变化——我们不想迁移 database 每次我们更改状态的内存表示。

    因此,我们的想法是我们在存储库中有两个可用的功能

    • 获取域在内存中的表示,并将其转换为存储的形式
    • 另一个采用存储的形式,并将其转换为内存中的表示形式。

    通常,持久化表单将具有消息的特征(从过去发送到现在)。在将持久化表单转换为领域使用的当前模型时,通常使用一种消息构建器方法(领域逻辑提供构建器,它具有稳定的 api,但不一定是稳定的实现)。

    【讨论】:

      猜你喜欢
      • 2016-05-01
      • 1970-01-01
      • 1970-01-01
      • 2011-04-02
      • 2019-04-23
      • 2018-01-15
      • 1970-01-01
      • 2013-12-05
      • 1970-01-01
      相关资源
      最近更新 更多