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

如何将后端BaaS化:业务逻辑的拆与合

反过来看,如果我们拆解得太粗,调用链路倒是短了,但是这个微服务的复用性就差了,更别提因为高耦合带来的复杂且冗余的数据库表结构,让我们后续难以维护。我画了个图,你感受下。...用一句话简单总结,DDD 就是一套方法论:通过对业务分层抽象,分析定义出领域模型,用领域模型驱动我们设计系统,最终将复杂的业务模型拆解为独立运维的领域模型。...实际我自己在使用微服务开发的过程发现,微服务整体应该是一个动态网络结构,随着业务的发展,这个网络结构也会发生变化。...其次那些跟业务逻辑无关的节点,逐渐被边缘化,甚至消失。我们看这些聚集成团的节点,如果团里的点聚合太近了,其实是不适合拆分的,它们整体应该作成一个微服务。...我们吸一口气,氧气进入肺部,血液循环将氧气按顺序流经我们每个器官,这就是请求链路。每个器官一接收到新鲜血液,就会吸取氧气返回二氧化碳,最终血液循环将二氧化碳带到肺部呼出,这个就是数据返回链路。

47650

如何将后端BaaS化:业务逻辑的拆与合

反过来看,如果我们拆解得太粗,调用链路倒是短了,但是这个微服务的复用性就差了,更别提因为高耦合带来的复杂且冗余的数据库表结构,让我们后续难以维护。我画了个图,你感受下。 ?...用一句话简单总结,DDD 就是一套方法论:通过对业务分层抽象,分析定义出领域模型,用领域模型驱动我们设计系统,最终将复杂的业务模型拆解为独立运维的领域模型。...实际我自己在使用微服务开发的过程发现,微服务整体应该是一个动态网络结构,随着业务的发展,这个网络结构也会发生变化。...其次那些跟业务逻辑无关的节点,逐渐被边缘化,甚至消失。我们看这些聚集成团的节点,如果团里的点聚合太近了,其实是不适合拆分的,它们整体应该作成一个微服务。...我们吸一口气,氧气进入肺部,血液循环将氧气按顺序流经我们每个器官,这就是请求链路。每个器官一接收到新鲜血液,就会吸取氧气返回二氧化碳,最终血液循环将二氧化碳带到肺部呼出,这个就是数据返回链路。

40420
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    PO、VO、DAO、BO、DTO、POJO能分清吗?

    BO(Business Object):业务对象,由 Service 层输出的封装业务逻辑的对象。...领域模型命名规约: 数据对象:xxxDO,xxx即为数据表名 数据传输对象:xxxDTO,xxx为业务领域相关的名称。 展示对象:xxxVO,xxx一般为网页名称。...PO (persistant object )持久对象 可以看成是与数据库中的表相映射的java对象。使用Hibernate来生成PO是不错的选择。...DAO (Data Access Objects) 数据访问对象接口 DAO是Data Access Object数据访问接口,数据访问:顾名思义就是与数据库打交道。夹在业务逻辑与数据库资源中间。...J2EE开发人员使用数据访问对象(DAO)设计模式把底层的数据访问逻辑和高层的商务逻辑分开.实现DAO模式能够更加专注于编写数据访问代码。

    1.1K20

    自定义MVC(导成jar包)+与三层架构的区别+反射+面试题

    3.自定义MVC工作原理图 4.MVC实现 通过XML对自定义MVC框架进行3步增强 一、反射增强第一步: 二、反射增强第二步: 将一组相关的操作放到一个Action中(反射调用方法) 三、反射增强第三步...( •̀ ω •́ )✧ 三层架构是一个经典的分层思想,将开发模式分为三层,每个人专注自己擅长模块即可 MVC是一种设计模式,其目的是让html和业务逻辑分开 三层架构:请看下去,看到这里已经很棒了‍‍‍‍‍‍‍‍‍‍‍‍...数据库中用于存放数据,而我们通常选择会用一个专门的类来抽象出数据表的结构,类的属性就一对一的对应这表的属性。 ·一般来说,Model实体类库层需要被DAL层,BIL层和UI层引用。...层被BIL层调用 3.业务逻辑层(BLL)        →快了 ·BLL层好比是桥梁,将UI表示层与DAL数据访问层之间联系起来。...所要负责的,就是处理涉及业务逻辑相关的问题,比如在调用访问数据库之前,先处理数据、判断数据。 BLL层只被UIL层引用 用户表现层(UIL),就是用户看到的主界面。

    39120

    【DBMS 数据库管理系统】数据仓库 ( 数据仓库简介 | 操作型数据与分析性数据对比 | 数据仓库特征 | 特征一 : 面向主题组织数据 | 面向应用 | )

    决策支持系统 ) 服务基础的 分析型数据库 ; 数据 : 用于存储 大量的 只读数据 ; 应用场景 : 为管理者 决策 提供相关信息 ; 数据仓库 与操作系统分离 , 基于标准的企业模型集成..., 和 准确性 ; 存储介质改变 : OLTP 应用只是将传统的业务活动 , 从纸质介质 , 转为电子信息 , 系统中的数据 与 现实中被替代的纸质文档对应 ; 上述 OLTP 面向应用的数据组织 ,...数据 , 与 数据处理 是分开的 , 一个客观实体的数据 , 与不同的应用场景捆绑 , 无法统一 , 分散存储在不同的表中 , 如商品信息 , 分别存储在采购子系统 , 销售子系统 , 库存子系统中..., 数据被分开存储 ; 面向应用 数据组织方式 缺点 : 数据抽象程度太低 , 数据 与 应用没有分离 ; 引入数据仓库 : 应该将 数据 从 数据处理 中抽象出来 , 组成和具体应用独立的 数据仓库...; 面向应用 数据组织方式 优点 : 操作性好 : 将 数据库 与 企业的业务逻辑 对应 , 可操作性高 ; 方便转换 : 方便 企业 将原有的纸质业务 , 转为计算机处理的业务 ; 支持 OLTP 应用

    82800

    springboot第5集:如何让多模块的项目结构更加清晰、易于理解

    此外,base文件夹还可以包含一些抽象类、接口等,供具体的业务逻辑模块重写或实现。这些类或接口可能涉及到与应用程序整体设计相关的问题,例如数据访问、服务层、权限管理等等。...这样做也有助于将值对象与其他类型的类分开,以便更容易地维护和管理代码。...domain 在Spring Boot的多模块应用中,domain文件夹通常用于存储与业务领域相关的类和接口。这些类和接口通常表达了业务模型中的实体、值对象、聚合以及事件等,可用于实现业务逻辑。...通常包含与数据库记录间映射的方法和逻辑。 Service层对象:这些对象是对业务逻辑进行封装的对象,由一个或多个关联的DAO对象或Entity对象组成。...这样做也有助于将值对象与其他类型的类分开,以便更容易地维护和管理代码。

    75230

    Java开发中PO、VO、DAO、BO、DTO、POJO 含义

    DAO(Data Access Objects) 数据访问对象接口 DAO是Data Access Object数据访问接口,数据访问:顾名思义就是与数据库打交道。夹在业务逻辑与数据库资源中间。...J2EE开发人员使用数据访问对象(DAO)设计模式把底层的数据访问逻辑和高层的商务逻辑分开。实现DAO模式能够更加专注于编写数据访问代码。 DAO模式是标准的J2EE设计模式之一。...开发人员使用这个模式把底层的数据访问操作和上层的商务逻辑分开。...MVC的简单定义: M层负责与数据库打交道; C层负责业务逻辑的编写; V层负责给用户展示(针对于前后端不分离的项目,不分离项目那种编写模版的方式,理解V的概念更直观)。 ?...(也可DO) 数据传输对象:xxxDTO,xxx为业务领域相关的名称。 展示对象:xxxVO,xxx一般为网页名称。 业务对象:xxxBO,xxx是业务名称。

    90370

    HIBERNATE 持久化基础

    狭义上的对象持久化是指将域对象永久保存至数据库中,而广义上的对象持久化则包括与数据库相关的各种操作。 (1)保存:将域对象永久保存至数据库中。 (2)更新:更新数据库中域对象的状态。...随着数据库技术的成熟,应用软件由单层向双层发展。在双层应用中,主要包括存放数据的数据库层以及将视图同业务逻辑混合的应用层。例如,一个JSP文件包括网页代码、接收请求与响应的代码以及处理业务逻辑的代码。...例如,在删除班级时,业务逻辑层首先获取该班级的所有学生信息并删除,然后再删除班级。 (3)数据层:对应用的业务数据进行存储与管理。例如,在学员管理系统数据库中,对学生、班级等业务数据进行保存。...由三层结构可知,业务逻辑层不仅负责业务逻辑,而且直接访问数据库,提供业务数据的增、删、改、查等功能。为了将数据库访问细节与业务逻辑分开,可以将数据访问独立出来作为持久层。...其中,V (View)与 C(Controller)分别指视图与控制器,M (Model)是业务逻辑与数据库逻辑之间的桥梁。

    11010

    大型项目如何选择ORM:Active Record 还是 Data Mappers

    每次都要看着数据库客户端,不然属性名称没法写。 容易把字段的类型弄错,varchar类型的属性传入了int。 容易写出SQL注入漏洞。...ORM的两种实现哲学 我们将ORM的思想拆分之后会发现它就两个功能。 数据操作 - 对数据对象做变更,就是我们常说的业务逻辑。...ActiveRecord上手非常快,业务逻辑和持久化逻辑在一个对象里一起解决,封装越好的框架持久化逻辑对编程人员越透明,程序员甚至不用知道底层数据库使用的是MySQL还是MongoDB。...使用者完全不用关心save()方法执行后数据是存储到MySQL还是MongoDB,在开发过程中可以将精力全部放到业务逻辑,开发速度非常快。 三....Data Mappers 从面向对象的角度来说,将数据操作与数据持久化两个功能分开符合单一功能原则。这样设计出来的代码低耦合,扩展性强,性能有保证。

    2.2K50

    开发 | 电商小程序数据库该如何设计?这 2 个方法拯救你

    虽然目前大家使用知晓云开发小程序,已经不再需要考虑后端代码的实现,只需要关心前端业务逻辑的展示即可。...但对于想要实现复杂业务的小程序开发者来说,后台数据库到底是建一张表还是多张表、每张表分别存储什么信息、表与表之间如何关联等等问题仍然是一个令人头疼的问题。...将数据按照逻辑思维分成不同的块 这个规则其实就是「三范式」中的第一范式(1 NF),即属性具有原子性,不可再分解。...只要数据列中出现数据重复,就要把表拆分开来。 我们把邮寄信息从原表中拆出,通过主键 address_book_id 相关联。这样当订单被删除时,也不会影响到用户的地址信息。 ? 3....最后的最后,悄悄透露一个好消息:为了支持更加复杂的业务逻辑,云函数功能已经正式进入筹备阶段,相信不久的将来就可以与大家正式见面啦。

    85810

    「查缺补漏」,DDD 核心概念梳理

    应用层 应用层不应该有业务逻辑。它是很薄的一层,理论上不应该有业务规则或逻辑,主要面向用例和流程相关的操作。...领域模型的业务逻辑主要通过实体和领域服务来实现,采用充血模型来时先所有与之相关的业务功能。充血模型后面会解释。...DDD 分层架构将业务逻辑层的服务拆分到了应用层和领域层。应用层快速响应前端的变化,领域层实现领域模型的能力。...充血模型和贫血模型的区别 贫血模型:数据和业务逻辑分开到不同的类中,比如 Model 类和 Service 类。 充血模型:数据和业务逻辑封装在同一个实体类中。...八、值对象 值对象概念 值对象描述了领域中的一件东西,这个东西是不可变的,它将不同的相关属性组合成了一个概念整体。

    82620

    软件设计:DAO层该如何设计

    首先what: dao(data access object),数据访问对象,既然是对象那么就有封装,他封装了业务及相关数据与数据库进行交互的一系列的接口。...2.设计一个dao层,上面所有的业务层都调用这个dao层的接口,这样就实现了软件的重用性。 3.dao层的存在使得业务逻辑层跟访问数据库的代码分开了。...3.考虑软件在不通数据库上的迁移。 4.dao层是用来实现业务及相关数据和数据库交互的桥梁,那么dao层就需要对数据库的操作进行一系列的封装,包括增删改查,数据库的事务,存储过程,触发器等等操作。...原因是:如果一次业务逻辑需要调用多个dao的方法,一旦某个dao的方法失败,造成回滚,则已经执行的那些DAO则无法回滚。...dao层的操作是对业务的一个分解,把一个完整的业务分解到数据库中的相关表中。

    1.5K30

    CQRS模式学习

    由于存在增删改与查询逻辑有差异的这个问题,为了更好的针对差异进行抽象,我们可以将它们分开进行设计。...CQRS本质 由于存在增删改与查询逻辑有差异的这个问题,为了更好的针对差异进行抽象,我们可以将它们分开进行设计。...CQRS本质上是一种读写分离设计思想,这种框架设计模式将命令型业务和查询型业务分开单独处理。...甚至可以针对读取操作使用mongo或者es等nosql数据库对查询逻辑进行增强。 分离后的数据将存在在不同的数据库中,Q的数据由C端同步过来。...大多数复杂的业务逻辑被分到写模型。 读模型会变得相对简单。 查询更简单:通过将具体化视图存储在读取数据库中,应用程序可在查询时避免复杂联接。

    46420

    JavaWeb(六)之MVC与三层架构设计

    但是在写一些项目时,还是会很麻烦,原因是业务逻辑代码,与数据库交互的代码,HTML代码这些类别,风格,作用完全不同的都混杂在了一起,造成的结果是代码的维护性,可读性以及扩张性都非常差,比如要改一个需求,...二、javaWeb开发模式之Model2(MVC) 2.1、概述   为了改进上面所说的缺点,也就是将业务逻辑代码放一起,显示页面的HTML代码放一起,与数据库交互的代码放一起,这样开发思路更加清晰,维护起来也更加方便...M:Model 模型,代表着业务逻辑代码与数据库代码,V:View 对数据的展示代码,比如JSP页面,就是专门用来展示数据,美化页面的 。   ...,在将数据显示在JSP中,在将JSP发送回浏览器,显示在用户看,   所以我们经常说,JSP就是View层,给用户看的,Servlet作为控制流程,而编写操作数据库代码,业务逻辑代码就属于Model。...而MVC是一种设计模式,目的是让HTML代码和业务逻辑代码分开,让代码看起来更加清晰,便于开发。      如果说他们有关系的话:只能说他们有共同的点,分层,解耦。

    1.8K81

    8000字,详解数据建模的方法、模型、规范和工具!

    但将半结构化/非结构化数据转化为结构化数据,然后再利用关系型数据库处理仍然是一种通用的主流数据处理方案。...牢牢掌握事实表的粒度,就能够将所有可能存在的维度区分开来。 (6)确认事实(用于度量) 事实,涉及来自业务过程事件的度量,基本上都是以数据值表示。...主要从数据业务特性和访问特性两个角度来考虑:将业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者物理模型;将高概率同时访问的数据放一起,将低概率同时访问的数据分开存储。...(3)公共处理逻辑下沉及单一 底层公用的处理逻辑应该在数据调度依赖的底层进行封装与实现,不要让公用的处理逻辑暴露给应用层实现,不要让公共逻辑在多处同时存在。...通常,设计顺序依次为:概念模型->逻辑模型->物理模型。 维度表设计要点: 维度是维度建模的基础和灵魂。在维度建模中,将度量称为"事实",将环境描述为"维度",维度是用于分析事实所需要的多样环境。

    4.3K10

    数据建模方法模型规范工具全解

    但将半结构化/非结构化数据转化为结构化数据,然后再利用关系型数据库处理仍然是一种通用的主流数据处理方案。...牢牢掌握事实表的粒度,就能够将所有可能存在的维度区分开来。 (5)确认事实(用于度量) 事实,涉及来自业务过程事件的度量,基本上都是以数据值表示。...主要从数据业务特性和访问特性两个角度来考虑:将业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者物理模型;将高概率同时访问的数据放一起,将低概率同时访问的数据分开存储。...(3)公共处理逻辑下沉及单一 底层公用的处理逻辑应该在数据调度依赖的底层进行封装与实现,不要让公用的处理逻辑暴露给应用层实现,不要让公共逻辑在多处同时存在。...通常,设计顺序依次为:概念模型->逻辑模型->物理模型。 维度表设计要点: 维度是维度建模的基础和灵魂。在维度建模中,将度量称为"事实",将环境描述为"维度",维度是用于分析事实所需要的多样环境。

    76540

    DApp系统开发采用是三种网络类型

    与主链的数据是分开存放的  ├──config.json//应用的节点配置文件,目前主要用于配置受托人秘钥  ├──contract//合约目录  │└──domain.js//域名合约的实现代码  ├...如果将区块链视为数据库、数据源,  智能合同基本上是一个数据库操作脚本,  它决定了如何在区块链上存储和修改数据。  ...智能合同开发  实现你的业务逻辑  曾经我在这个博客里写过我们的开发理念  在asch dapp中实现一个业务逻辑,大概思路如下  6.1定义你的数据模型  在这个环节,你需要考虑的是在区块链中保存什么数据或状态...,你的账单内容是什么哪些字段需要建立索引,以提高客户端查询速度  6.2实现合约逻辑  这个环节,你需要考虑的是一个事务或一个调用会修改哪些状态,比如资产余额,账户属性等我们在sdk中提供了丰富的接口可供调用...,具体可参考sdk接口文档  6.3实现查询接口  在这个环节,你需要考虑的是如何给前端返回数据,比如区块,交易,各种合约业务状态的查询等也可以可用这个通道将一些非全局状态保存到本地节点,我们会在后续章节介绍这些高级用法

    33320

    使用 Java @Annotations 构建完整的 Spring Boot REST API

    1 案例分析 API 是一个简单的模块,用于从更复杂的系统中实现业务实体的 CRUD 操作,旨在协调和协调与企业、机构和实体组相关的经济信息。为简单起见,API 使用 H2 内存数据库。...它通过分离模型、视图和控制器的角色将业务逻辑与 UI 分离。MVC 模式的核心思想是将业务逻辑从 UI 中分离出来,允许它们独立更改而不相互影响。 在此设计模式中,M 代表模型。...它代表了数据和业务逻辑的形状。模型对象检索模型状态并将其存储在数据库中。它的模型通常由服务层处理并由持久层持久化的领域对象组成。...此声明与与业务实体模型相关的代码中显示的内容略有不同。反向关系声明通过属性“ mappedBy. ”来区分。 5 数据传输对象 数据传输对象是一种非常流行的设计模式。...数据访问对象 (DAO) 模式的一般目的是通过将数据访问逻辑与业务逻辑和表示逻辑分开来避免这些问题。此模式建议将数据访问逻辑封装在称为数据访问对象 [3] 的独立模块中。

    3.4K20

    CA,给了数据库,给了机器,为啥也扩不了容?

    ,为了提高资源利用率(程序员才没有考虑什么资源利用率,更多的是图方便),业务A把用户个性化的数据也放在这个库里: table_A(uid, A业务的个性化属性) 业务A有一个需求,即要展现用户公共属性,...” 额,然而,这个理由,好像在大boss那解释不通… 业务B的大boss:“赶紧加几台机器,拆分开” 业务B的rd一脸无奈:“加机器加实例也扩容不了” 业务B的大boss对业务2的rd吼道“还想甩锅,拖出去祭天...那,如何解除公共数据库与业务数据库的耦合? 第一步:公共数据访问下沉服务化 ?...接口) 一次取得共性数据(调用通用的RPC接口) 两种方式相比: 之前的方式其实业务代码可能会更简单一些,因为它是将这个业务逻辑放在了SQL语句中,但是导致数据库耦合在了一起 后面这种方式就是业务的代码会更复杂...,会变成多次访问,将原来在SQL中进行的逻辑计算变成业务代码中的逻辑计算,但是数据库解耦了 业务复杂,数据量大,并发老大,对扩展性要求更高的架构,一定是后者。

    87270

    高度可定制化业务系统架构探索(一):字段可定制化

    属性可以分为3个大类: 分类 定义 举例 业务性质 描述和业务本身的定义,业务逻辑相关的属性 字段类型、校验器 交互性质 描述在界面上用于控制该字段的展示逻辑或交互逻辑的属性 字段在表单中是否需要展示(...类型相关 控制该字段的数据类型时使用 type 存储相关 导出数据时,该字段以什么形式进行转化 save, create 提交相关 提交数据到后端接口时,该字段要怎么处理 map, flat 逻辑相关...这些表与实际的业务表分开,与业务表没有本质上的关联,如果不使用字段定制化的能力,这些表可以从业务系统中删除而不影响原有业务数据。...我们采用微服务架构将字段的定制化设计为独立于原有业务的服务,再改造原有业务中关于数据读取的逻辑来配合微服务获取最终的结果。...业务系统与那些通用的系统之间有着明确的区别,即业务系统有非常明确的领域边界,业务内某些逻辑是固定的,这些固定的,或领域特有的,就没有必要做成通用化的东西,而应该提炼成独立的领域组件,这样才能避免无止尽的自定义搭建

    2.3K20
    领券