首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

领域模型可以知道存储库吗?

领域模型是一种描述系统中各个组件之间关系的模型,它可以帮助开发人员更好地理解和设计系统。存储库是一种用于存储和管理数据的地方,通常用于数据库或文件系统。

领域模型可以包含存储库,但它们通常不会直接与存储库相关联。相反,领域模型通常描述了系统中各个组件之间的关系,包括数据模型、业务逻辑和用户界面。存储库则是用于存储和管理数据的地方,它可以是一个数据库或文件系统。

在领域模型中,存储库通常被称为数据存储或数据访问层。这些层负责将数据存储到数据库中,并从数据库中检索数据。领域模型中的其他组件,如业务逻辑层和用户界面层,则与数据存储或数据访问层进行交互,以获取和存储数据。

总之,领域模型可以包含存储库,但它们通常不会直接与存储库相关联。相反,领域模型描述了系统中各个组件之间的关系,包括数据模型、业务逻辑和用户界面。存储库则是用于存储和管理数据的地方,它可以是一个数据库或文件系统。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

  • Spring Web 应用的最大败笔

    开发人员在使用Spring应用是非常擅长谈论依赖注入的好处。不幸的是,他们不是那么真的利用它的好处,如单一职责原则,分离关注原则。如果我们一起来看看大部分Spring的Web应用程序,常见的错误的设计如下: 1.领域模型对象用来存储应用的数据(当作DTO使用),领域模型是贫血模型这样的反模式。 2.服务层每个实体有一个服务。 问题是这样很普遍,错误在哪里呢? Spring的web应用程序之所以这样是因为他们做事物的方式一直都是这样做的,老习惯难改,特别是如果他们是高级开发人员或软件架构师,这些人捍卫这样做的论据之一是:我们的应用程序遵循关注分离的原则,因为它已经被分为若干层,每个层有自己的特定职责。 1. Web层负责处理用户输入,并返回正确的响应返回给用户。 web层与服务层通信。 2.服务层作为一个事务边界。它也负责授权和包含我们的应用程序的业务逻辑。服务层管理的域模型对象,并与其他服务和存储库层进行通信。 3.存储库/数据访问层负责与所使用的数据的存储进行通信。 分离关注(Soc)是分离计算机程序为不同的部分,每个部分有一个关注聚焦,一个典型的Spring Web应用在一定程度上遵循这一原则,但现实是,该应用程序有一个整体的服务层,它有太多的责任。更具体地,服务层有两个主要问题: 1.在服务层发现业务逻辑 业务逻辑被分散在各个服务层。如果我们需要检查一个业务规则是如何实现的,我们必须先找到它。这可能并不容易。此外,如果相同的业务规则需要在多个服务类,问题是,规则需要从一个服务到另一个简单地复制。这将导致维护的噩梦。 2.每个领域模型一个服务 这完全违反了单一职责原则,它被定义为如下:单一职责原则指出,每一个类都应该有一个责任,责任应该由类完全封装。其所有的服务应该狭义与责任相一致。(不应将原属于领域模型的行为方法等划放在服务中实现,对象不但有属性还有行为) 服务类有很多依赖,以及大量的循环依赖。更像网络紧密耦合和单片服务。这使得很难理解,维护和重用。这听起来有点苛刻,但一个Spring的web应用的服务层往往是最容易出问题的部分。幸运的是,所有的希望都不会丢失。 1. 我们必须将我们的应用程序的业务逻辑从服务层迁移到领域模型类中。 举个例子:假设我是一个服务类,你是一个域模型对象。如果我让你从屋顶上跳下来,你会喜欢我这样的决定吗?(跳下来会摔伤,自己没有脑子或被洗脑,变成僵尸,只听从执行,不思考自己的安全,这就是贫血模型的问题) 将业务逻辑从服务层迁移到域模型类有下面三个优势: (1)我们的代码将以逻辑方式切割,服务层只要关注应用逻辑,而我们的领域模型关注业务逻辑。 (2)业务逻辑只存在一个地方,容易发现修改。 (3)服务层的源代码是清洁的,不包含任何复制粘贴代码 2. 将每个实体服务切割为单一目标的更小的服务。 比如,有一个单一服务类,提供对人员和用户账户的CRUD操作,我们应该将它分为两个独立的服务类: 第一个是对人员的提供CRUD操作 第二个是提供与用户账户相关的操作。 好处:每个服务类中有一个逻辑组职责。每个服务类的依赖较少,这意味着他们不再是紧耦合的源头。他们是较小的和松耦合的组件。服务类更容易理解,维护和重用。 这两个简单的步骤将帮助我们使得我们的应用程序架构更干净,有助于同行开发商提高生产力和幸福。

    01

    如何运用领域驱动设计 - 存储库

    在上一篇文章中,我们已经了解过领域驱动设计中一个很核心的对象-聚合。在现实场景中,我们往往需要将聚合持久化到某个地方,或者是从某个地方创建出聚合。此时就会使得领域对象与我们的基础架构产生紧密的耦合,那么我们应该怎么隔绝这一层耦合关系,使它们自身的职责界限更加清晰呢?是的,这就要用到我们今天要讲的内容 - 存储库。在很多地方,我们喜欢叫它为仓储,特别是在现有的AspNetCore应用中,大量的应用都在引入Repository这种东西。那么究竟什么是存储库呢?我们现在的使用方式是正确的吗?它在领域驱动设计中又扮演着怎样的角色呢?本文将从不同的角度来带大家重新认识一下“存储库”这个概念,并且给出相应的代码片段(本教程的代码片段都使用的是C#,后期的实战项目也是基于 DotNet Core 平台)。

    03

    浅谈我对DDD领域驱动设计的理解

    从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决。 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品。所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的。 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备。但是最近由于各种原因,导致服务经常出故障。所以,我们希望通过各种措施提高服务的质量和稳定性。其中的一个措施就是希望能做一个灰度发布的平台,这个平台可以提供

    010

    DDD领域驱动设计在微服务架构的应用

    我们都自诩面向对象编程,OOP思想更是熟读于心,然而随着业务日益复杂,代码越来越臃肿,这时感觉之前面向对象的理论也毫无用武之地。到底哪个环节出问题了?笔者认为造成这种局面的原因很大程度是我们忽视了业务建模和设计的重要性。我们通常启动一个项目后,架构师等技术人员会拿到产品人员的产品需求然后开始各种建模、各种拆分,也是在技术内部形成共识和就进入实施阶段。这实际就犯了一个严重的错误:技术和业务未达成业务模型的共识。2003年Eric Evans发布首版《领域驱动设计》实际就为了解决这个问题。领域驱动设计更大层面是提供了方法论的支持,所以在具体实施各有不同。今天我们就介绍下我们在实践过程领域驱动设计的一些经验与心得。

    02
    领券