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

事件来源。使用子列表聚合还是使用ParentID聚合?

在云计算领域中,事件来源是指触发某个事件的具体来源或引起事件发生的原因。在处理事件时,可以使用子列表聚合或者使用ParentID聚合来对事件进行分类和组织。

  1. 子列表聚合:使用子列表聚合的方式,是将事件按照不同的来源进行分类,每个来源都有一个独立的列表。这种方式可以方便地对不同来源的事件进行管理和分析。例如,一个网站可能有多个页面,每个页面都可能触发不同的事件,可以将每个页面作为子列表,将相应的事件归类到对应的子列表中。
  2. ParentID聚合:使用ParentID聚合的方式,是通过给每个事件分配一个唯一的标识符,然后使用ParentID来建立事件之间的关系。这种方式可以将相关的事件组织在一起,形成一个事件树状结构。例如,一个订单系统中,可以使用订单ID作为ParentID,将与该订单相关的各个事件(如下单、支付、发货等)都归类到该订单下。

选择使用子列表聚合还是使用ParentID聚合,取决于具体的业务需求和数据结构设计。以下是两种聚合方式的优势和应用场景:

子列表聚合的优势:

  • 简单直观:每个来源都有独立的列表,易于理解和管理。
  • 灵活性高:可以根据具体的业务需求,灵活地添加、删除或调整子列表。
  • 适用于多来源场景:当事件来源较多且相互独立时,使用子列表聚合可以更好地组织和管理事件。

子列表聚合的应用场景:

  • 网站分析:对于一个复杂的网站,可以将不同页面作为子列表,分别统计每个页面的访问量、点击量等指标。
  • 应用监控:对于一个分布式应用系统,可以将不同的组件或服务作为子列表,分别监控其运行状态和性能指标。

ParentID聚合的优势:

  • 关联性强:通过ParentID建立事件之间的关系,可以方便地查找和分析相关的事件。
  • 层次结构清晰:形成事件树状结构,可以清晰地展示事件之间的层次关系。
  • 适用于关联性强的场景:当事件之间存在明显的关联性,需要进行上下文分析时,使用ParentID聚合更为合适。

ParentID聚合的应用场景:

  • 订单管理:对于一个电商平台,可以使用订单ID作为ParentID,将与订单相关的各个事件都归类到该订单下,方便订单的管理和分析。
  • 故障排查:对于一个复杂的系统,可以使用故障ID作为ParentID,将与同一故障相关的各个事件组织在一起,方便进行故障排查和分析。

腾讯云相关产品和产品介绍链接地址:

  • 腾讯云日志服务(CLS):https://cloud.tencent.com/product/cls
  • 腾讯云事件消息队列(CMQ):https://cloud.tencent.com/product/cmq
  • 腾讯云云监控(Cloud Monitor):https://cloud.tencent.com/product/monitor
页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

java将有父子关系的list转换为树形结构

项目需求:在项目对接过程中,被调用方给返回了一个对象列表,对象中包含id和parentId,但返回的数据没有层级结构,需要调用方自己组装成树级结构;需求分析:由于返回的是否无序的列表,首先需要找到顶级结构...,然后更加parentId获取级,递归循环,指定子级没有后代信息;需求实现:想到两种方式:第一种、首先想到的是循环列表,对一个列表进行多次循环,每次只找一级,即可实现;第二种、先根据parentId聚合...,然后再对聚合map进行递归;相对来说第二种方式,比较合适;但是需要考虑到parentId不存在的情况;先找到顶级,过滤条件为parentId不存在://没有parentid List...parentId为key进行聚合,如果parentId为null或空字符串,聚合时会报错,所以排除了parentId不存在的对象;这里需要添加到顶级 public List

1.5K40

《腾讯大家》小程序开发总结

基于聚合页面的传播需求,腾讯大家小程序解决了在移动端聚合及快速查找历史内容的需求。绑定小程序以后,在推送单篇文章时,可以配合推送作者文章列表、相关文章列表等定制页面。...腾讯大家小程序呈现内容包含:首页首页聚合(tab)、作者列表(tab)、专栏聚合(tab)、个人中心(tab)、内容底层、作者底层、栏目底层、活动底层(战队底层,专题底层)。...1.3 内容底层展示 小程序的核心是一个响应的数据绑定系统,所以我们要展示一篇资讯详情,需要有一份数据,通过这份数据来判断这篇资讯是要渲染段落、表格、列表、图片、还是视频。...1.9 浏览记录功能 浏览记录模块在个人中心页面中: 数据来源为用户浏览文章时的上报,服务端做时间戳记录(浏览去重)等工作。 在开发列表加载逻辑时,需要注意验证一下拿到数据的一致性。...-- 组件事件绑定 --> {{title}}

2.2K30

《腾讯大家》小程序开发总结

基于聚合页面的传播需求,腾讯大家小程序解决了在移动端聚合及快速查找历史内容的需求。绑定小程序以后,在推送单篇文章时,可以配合推送作者文章列表、相关文章列表等定制页面。...腾讯大家小程序呈现内容包含:首页首页聚合(tab)、作者列表(tab)、专栏聚合(tab)、个人中心(tab)、内容底层、作者底层、栏目底层、活动底层(战队底层,专题底层)。...1.3 内容底层展示 小程序的核心是一个响应的数据绑定系统,所以我们要展示一篇资讯详情,需要有一份数据,通过这份数据来判断这篇资讯是要渲染段落、表格、列表、图片、还是视频。...1.9 浏览记录功能 浏览记录模块在个人中心页面中: 1.数据来源为用户浏览文章时的上报,服务端做时间戳记录(浏览去重)等工作。 2.在开发列表加载逻辑时,需要注意验证一下拿到数据的一致性。...-- 组件事件绑定 --> {{title}}

5.3K110

OneCode低代码引擎,领域驱动设计(DDD)技术实践(一)

前言 领域驱动设计(简称 ddd)概念来源于2004年著名建模专家Eric Evans 发表的他最具影响力的书籍:《领域驱动设计——软件核心复杂性应对之道》(Domain-Driven Design –...(1)通过数据库建模 仓储工具中使用频率最高的是数据库的转换应用,用户通过数据库工具完成数据源配置。 ?...执行事件传递 (4)聚合分类 ? (5)聚合聚合根设计,通常来标识其独立的域应用,具有全局唯一性的特点。...通常只包含简单的值关系,功能上也仅限于,查询列表、保存表单等简单应用。 ?...视图工厂中仍然延续这一风格设计将普通单一的组件通过,后端JAVA代码的聚合将常用功能以及辅助组件进行业务封装形成独立的视图组件。 常用列表功能 ? 常用配置 列表信息配置 ?

1.3K41

有空就来学Hystrix RPC保护的原理,RPC监控之滑动窗口的实现原理

Hystrix滑动窗口的核心实现是使用RxJava的window操作符(算子)来完成的。使用RxJava实现滑动窗口还有一大好处就是可以依赖RxJava的线程模型来保证数据写入和聚合的线程安全。...然后,桶计数流以事件流作为来源,将事件流中的事件按照固定时间长度(桶时间间隔)划分成滚动窗口,并对时间桶滚动窗口内的事件按照类型进行累积,完成之后将桶数据弹射出去,形成桶计数流。...桶计数流bucketedCounterStream使用window操作符以300毫秒为一个时间桶窗口,将原始的事件流进行拆分,每个时间桶窗口的3事件聚合起来,输出一个新的Observable(流)。...bucketedCounterStream的处理过程 bucketedCounterStream的flapMap扁平化操作是通过调用reduceBucketToSummary方法完成的,该方法首先将每一个时间桶窗口内的Observable流内的元素序列转成一个列表...”操作,将Observable流中的3事件的累加结果计算出来。

69710

讲真,别再拿着聚合寻找限界上下文了

聚合分组法和它的问题 在事件风暴工作坊中,常用的划分限界上下文的方法是: 对前一步(事件风暴)产生的聚合进行分组,通过业务的内聚性和关联度划分边界,结合限界上下文的定义进行判断,并给出上下文名称。...使用聚合分组法往往导致把带着这样的聚合简单的放到某个限界上下文中。...隐藏的划分方案 还很可能是这种情况:在使用聚合分组法时,架构师已经有一个隐藏在心里的模糊的划分方案,在划分限界上下文时都是往该方案上靠。...我们必须把系统分解为较小的组成部分,无论在概念还是在实现上。 有时,企业系统会集成各种不同来源的子系统,或者包含诸多属于完全不同领域的应用程序。要把这些不同部分中隐含的模型统一起来是不可能的。...每个领域事件都是为了解决某个问题,它和它相关的领域模型就应该放在这个问题域对应的限界上下文里。 比如“活动已上线“这个事件,由运营人员在配置时触发,会导致用户可以开始参与活动。

1.3K21

DDD领域驱动设计的概念解析

我们按照层次进行概念划分的话,大概是: 事件风暴、领域事件、限界上下文 领域、域、核心域、通用域、支撑域 聚合聚合根 实体、值对象 贫血模型、充血模型、失血模型 以上是基本包含所有概念,其实概念就是事物的共同本质特点的抽象...而动词则表示一个事件或动作,如:商品下单、订单已付款 对应领域事件或者命令 设计过程中可以使用一些表格,来记录事件风暴和微服务设计过程中产生的领域对象及其属。...通用域 没有太多个性化的诉求,同时被多个子域使用通用功能域是通用域。...如果把聚合比作组织,那么聚合根就是这个组织的负责人,这个组织的管理者。聚合根也称为根实体,它不仅是实体,还是聚合的管理者 首页它作为实体本身,拥有实体的属性和业务行为,实现自身的业务逻辑。...在聚合之间,他还是聚合对外的接口人,以 聚合根ID 关联的方式接受外部任务和请求,在上下文内实现聚合之间的业务协作。

1.1K20

商城项目-自定义组件用法

,这样就不用远程加载了 Array - 这里推荐使用url进行延迟加载,每当点击父节点时,就会发起请求,根据父节点id查询节点信息。...": 0, "isParent": true, "sort": 3 } ] 1.3.事件事件名称 说明 回调参数 handleAdd 新增节点时触发,isEdit为...itemValue 每个选项中用来作为值的字段名称 String id children 选项数组在父选项中的字段名称 String children multiple 是否允许多选 boolean...rules 自定义校验规则 Array 无 value 选择框的结果,可以通过v-model进行双向绑定 Array 无 label 提示用户的文字说明 String 无 2.5.说明: 无论是单选还是多选...3.2.属性列表: 属性名 说明 数据类型 默认值 url 上传文件的目标路径 String 无 value 上传成功的返回结果 单图片上传是String。

54820

后端开发实践系列之四——简单可用的CQRS编码实践

---- CQRS实现模式概览 常见误解 在网上搜索一番,你会发现很多关于CQRS的文章都将CQRS与Event Sourcing(事件溯源)结合起来使用,这容易让人觉得采用CQRS就一定需要同时使用Event...查询模型的数据来源 无论是单体还是微服务,所读数据的唯一正确来源(Single Source of Truth)最终都来自于业务实体(Entity)对象(比如DDD中的聚合根),基于此,所读数据的来源形式大致分为以下几种...: 所读数据来源于同一个进程空间的单个实体(后文简称“单进程单实体”),这里的进程空间指某个单体应用或者单个微服务; 所读数据来源于同一个进程空间中的多个实体(后文简称“单进程跨实体”); 所读数据来源于不同进程空间中的多个实体...事实上,在接收并处理事件时,存在2中风格,一种是本例中的仅将事件作为消息通知,然后调用其他服务的API接口完成同步,另一种是直接使用事件所携带的数据进行同步,更多关于这2种风格的比较,请参考笔者的《事件驱动架构...()方法获得 OrderSummaryRepresentation:用于返回聚合根的列表,仅仅包含Order本身的状态 OrderWithProductRepresentation:用于返回带有Product

1.2K40

走近DDD

通常除了它,还有通用域和支撑域。...使用域处理遗留系统 我们代码不是在真空里运行,它们免不了会跟一些遗留系统打交道,这些遗留系统的边界并不清晰。因此我们会将遗留系统放到一个域里,把它们的问题放到我们的设计之外。...最好建模的几天时间内保持每次讨论的结果一直保留并供下次讨论使用事件风暴的基本步骤: 1、在便利贴上写领域事件,梳理出业务流程,一般是橘色。...但是也有不是命令触发的事件,比如时间触发的事件。 如果存在一个执行动作的特定角色,那么可以在命令左下角使用亮黄色的便利贴记录角色名称。 命令也可以触发流程。...时间评估工具 时间评估工具是如下的一个经验表格: 作者Evans在原始表格里使用的单位是人时,然而根据我的经验,这个地方用人天还差不多…… 这个表格的好处是系统里关于业务的部分都很明确了,虽然时间还是经验得出的

34820

DDD的领域概念们

我们使用DDD,在面向业务变化时首先要理解业务的核心问题,即有针对性地进行关注点分离来找到相对内聚的业务活动形成问题域。...问题域内部是相对稳定的,即未来的变化频率不会很高,而问题边界是很容易变化的。也就是说,DDD的核心在于领域边界的识别和划分。...如果一个业务流程涉及到多个聚合根操作,不同聚合根之间可通过领域事件解耦,只不过这种是最终一致性的体现。...最后来看下领域事件,DDD提倡聚合之间产生的业务协同使用领域事件的方式来完成,领域事件就是将上游聚合处理完成这个动作通过事件的方式进行抽象。...DDD的领域概念基本就是上面说的这些了,但是在实际业务落地DDD时,我们会遇到一些问题的,比如最简单的就是有一个对象,目前没有业务行为,但是后续可能有业务行为,这种到底是抽象为值对象还是实体呢?

67620

领域驱动设计实践:支付系统建模

点击上方“芋道源码”,选择“设为星标” 管她前浪,还是后浪? 能浪的浪,才是好浪! 每天 10:33 更新文章,每天掉亿点点头发......定义解决方案空间中的有界上下文 在有界限的上下文中,应用战术性DDD模式来定义实体、聚合、领域服务、领域事件等。 使用上一步的结果来确定你的团队中的微服务。 以下是分析结果。...支付融合:支付细节的聚合视图。 而上下文地图将是这样的: 领域模型 从上面我们分析的场景和无所不在的语言中,我们可以确定以下聚合、实体、价值对象和领域事件 。...领域服务 在我们的实践中,域服务是为一个聚合体提供的无状态业务逻辑服务,遵循单一责任模式。通常情况下,我们会在领域服务中封装领域仓库、聚合变化和领域事件发布。...领域事件 领域事件可以使系统更具可扩展性 ,并避免任何耦合--一个聚合体不应该决定其他聚合体应该做什么,以及时间耦合--付款的成功完成并不取决于所有进程在同一时间可用。

1.2K10

领域驱动设计精粹(中)

电商案例 网上购物已经成为我们生活中不可分割的一部分,作为一个用户而言我们经历的流程有以下几点: 从商品列表页面选择需要的商品。 查查商品的促销活动,凑凑满减。 在购物车选择需要买的商品下单。...明确上下文边界后,我们跟不同岗位的人沟通即使使用相同词汇也能准确理解其含义。 领域专家和领域知识 领域驱动设计强调由领域专家带领大家进行领域建模。...拿上面的流程举例来说明,一个有经验的领域专家会带领大家通过事件风暴建模的方法进行域拆分,大致分为交易域、营销域、支付域、商品域、履约域。...聚合根也叫做根实体,它不仅仅是实体,还是实体的管理者。 聚合之间通过聚合根关联引用,如果需要访问其他聚合的实体,先访问聚合根,再导航到聚合内部的实体。即外部对象不能直接访问聚合内的实体。...本来是想着拿实际的例子来讲一遍事件风暴建模的过程,现在想想与其照本宣科的讲知识,不如写写经验和感悟来的实在。 事件风暴 VS 传统开发 事件风暴建模的标准流程可以很轻松地找到,这里不再赘述。

84320

当中台过气,微服务回归单体,DDD的意义何在?

针对一个复杂问题,使用分治的思想,还可以进一步拆分成问题。...我们以购物车场景为例来体会一下聚合聚合根的含义,在购物车中,加入购物车的商品列表构成了一个聚合,购物车 id 即聚合根,通过购物车 id,外界可以访问购买物品的列表信息、状态、下单总金额等。...针对以上事件,领域驱动提倡:领域事件的数据通信方式使用事件发布订阅的方式进行,不直接同步调用,而事件发布的本质则是一种低耦合的异步数据沟通方式。 同步调用有两点需要考虑的问题:分布式事务以及时耗。...在领域事件这种场景下,有一个更好技术选择,则是使用事件发布订阅的方式,还是拿用户购买物品支付发货场景为例,看看其实现过程: 用户支付下单后,支付域创建事件,持久化事件状态,在支付成功后发布事件,支付行为结束...04、总结 以上就是我对于领域驱动的一些浅见,如果你看完后还是感觉领域驱动有点形而上学,没关系,只要你记住,不管是技术还是生活,遇到事情多沟通,复杂问题先分解。 -End- 原创作者 | 吕昊俣

59244

领域基本概念字典

决定产品和公司核心竞争力的域是核心域,它是业务成功的主要因素和公司的核心竞争力。没有太多个性化的诉求,同时被多个子域使用的通用功能域是通用域。...命令可以是用户发起,也可以是第三方系统调用或者定时器触发等,最后对事件进行分类,整理出实体、聚合聚合根以及限界上下文。...而事件风暴正是 DDD 战略设计中经常使用的一种方法,它可以快速分析和分解复杂的业务领域,完成领域建模。...再进一步发展,事件驱动架构可以演变成事件源(Event Sourcing),即对聚合的获取并不是通过加载数据库中的瞬时状态,而是通过重放发生在聚合生命周期中的所有领域事件完成。...跨多个实体的业务逻辑通过领域服务来实现,跨多个聚合的业务逻辑通过应用服务来实现。 如果把聚合比作组织,聚合根则是组织的负责人,聚合根也叫做根实体,它不仅仅是实体,还是实体的管理者。

74920

万字长文助你上手软件领域驱动设计 DDD

划分子领域的过程存在很多经验因素,一个对该行业领域知识了如指掌的领域专家,可以在完成价值需求分析后,结合自身的领域经验,能够选择合适的聚类策略并给出稳定的领域列表。但,没有领域经验也没有关系!...一般对于一些领域通用的值对象是相对稳定的,这些类型通常属于通用领域,会被系统中几乎所有的限界上下文复用,那么这些领域模型就适合使用共享内核的方式。...转换为实体) 使用构建者组装聚合 注意!...(PS:假设设计之初难以判断聚合之间到底是关联关系,还是依赖关系,我们就统一使用身份标识符作为关系引用即可) 聚合间的依赖关系通常分为两种方式 职责的委派:一个聚合作为另一个聚合的方法参数, 就会形成职责的委派...聚合的创建:一个聚合创建另外一个聚合,就会形成实例化的依赖关系。 7.3.2.2 设计步骤 1. 理顺对象图 分析对象是实体还是值对象。 2.

1.7K31

领域基本概念字典

决定产品和公司核心竞争力的域是核心域,它是业务成功的主要因素和公司的核心竞争力。没有太多个性化的诉求,同时被多个子域使用的通用功能域是通用域。...命令可以是用户发起,也可以是第三方系统调用或者定时器触发等,最后对事件进行分类,整理出实体、聚合聚合根以及限界上下文。...而事件风暴正是 DDD 战略设计中经常使用的一种方法,它可以快速分析和分解复杂的业务领域,完成领域建模。...再进一步发展,事件驱动架构可以演变成事件源(Event Sourcing),即对聚合的获取并不是通过加载数据库中的瞬时状态,而是通过重放发生在聚合生命周期中的所有领域事件完成。...跨多个实体的业务逻辑通过领域服务来实现,跨多个聚合的业务逻辑通过应用服务来实现。 如果把聚合比作组织,聚合根则是组织的负责人,聚合根也叫做根实体,它不仅仅是实体,还是实体的管理者。

1.1K30

领域驱动实践总结(基本理论总结与分析V+架构分析与代码设计+具体应用设计分析)

2.通用域 没有太多个性化的诉求,同时被多个子域使用的通用功能域是通用域。 通用域则是你需要用到的通用系统,比如认证、权限等等,这类应用很容易买到,没有企业特点限制,不需要做太多的定制化。...聚合根也称为根实体,它不仅是实体,还是聚合的管理者。 首先它作为实体本身,拥有实体的属性和业务行为,实现自身的业务逻辑。...最后在聚合之间,它还是聚合对外的接口人,以聚合根 ID 关联的方式接受外部任务和请求,在上下文内实现聚合之间的业务协同。...分布式事务机制会影响系统性能,增加微服务之间的耦合,所以我们还是要尽量避免使用分布式事务。...事件总线是进程内模型,它会在微服务内聚合之间遍历订阅者列表,采取同步或异步的模式传递数据。

70520
领券