(19)国家知识产权局 (12)发明 专利申请 (10)申请公布号 (43)申请公布日 (21)申请 号 202211115381.9 (22)申请日 2022.09.14 (71)申请人 杭州杰竞科技有限公司 地址 310000 浙江省杭州市西湖区古墩 路 598号2#楼101-24、 101-25、 101-26号 (72)发明人 柏壑　陈玮　 (74)专利代理 机构 杭州鸿义专利代理事务所 (普通合伙) 33500 专利代理师 赵丹 (51)Int.Cl. G06F 8/20(2018.01) G06F 8/41(2018.01) G06F 9/54(2006.01) G06F 16/25(2019.01) (54)发明名称 面向微服务的领域对象的低代码管理系统 (57)摘要 本申请公开了一种面向微服务的领域对象 的低代码管 理系统， 包括： 业务设计模块， 以交互 式设计工具形式获取业务需求后输出支持领域 驱动设计的领域建模方案； 编译模块， 获取领域 建模方案， 使用指定技术栈为每个限界上下文生 成相应的微服务代码框架； 运行模块， 构建领域 模型操作代理对象， 以实现微服务完成具体的业 务逻辑。 本申请的方案将领域对象管理相关的流 程和数据交换 都由系统集中管 理， 形成模块化方 案， 流程标准化， 大大降低应用迭代对于业务对 象的维护成本， 让研发工作重心集中到核心领域 逻辑的设计和实现。 权利要求书1页 说明书6页 附图7页 CN 115543264 A 2022.12.30 CN 115543264 A 1.一种面向微 服务的领域对象的低代码管理系统， 其特 征在于， 包括： 业务设计模块， 以交互式设计工具形式获取业务需求后输出支持领域驱动设计的领域 建模方案； 所述领域建模方案包含领域边界及协同关系 单元、 领域对 象单元和状态信息管 理单元； 所述领域边界及协同关系 单元包括领域建模设计中的限界上下文定义、 限界上下 文之间的协同工作关系； 编译模块， 获取领域建模方案， 使用指定技术栈为每个限界上下文生成相应的微服务 代码框架， 对外根据限界上下文之间的协同工作关系生成微服务之间交互的统一接口， 对 内将领域对象单 元和状态信息管理单 元封装成标准 流程； 运行模块， 构建领域模型操作代理对象， 微服务根据业务需求向领域模型操作代理对 象请求对业务对象进 行访问或操作； 领域模型操作 代理对象根据领域模型在编译模块生成 的标准流程， 和微服务集群中其他服务中的代理对 象协同工作， 组成一个领域对 象的服务 网格， 完成领域对象的本地或远程加载、 组装和交付， 以实现微 服务完成具体的业 务逻辑。 2.根据权利要求1所述的面向微服务的领域对象的低代码管理系统， 其特征在于， 所述 领域对象单 元包括限界上 下文中的实体、 值对象、 聚合、 关联关系和领域关联图。 3.根据权利要求2所述的面向微服务的领域对象的低代码管理系统， 其特征在于， 所述 领域对象单 元中针对实体、 值对象、 聚合均描述 其中每个属性的类型、 描述和约束信息 。 4.根据权利要求2所述的面向微服务的领域对象的低代码管理系统， 其特征在于， 所述 领域对象单元中的领域关联图针对每个领域实体之间的关联关系进行定义， 包括关联类 型， 以及关联关系中的每一端可否为空； 所述关联类型包括一对一、 一对多、 多对一、 多对 多。 5.根据权利要求1所述的面向微服务的领域对象的低代码管理系统， 其特征在于， 所述 领域状态信息管理单 元包括资源库配置和领域事 件的定义。 6.根据权利要求5所述的面向微服务的领域对象的低代码管理系统， 其特征在于， 所述 资源库配置包含外部数据源地址配置， 以及各个实体和数据源中数据 表的映射关系和双向 转化策略。 7.根据权利要求6所述的面向微服务的领域对象的低代码管理系统， 其特征在于， 所述 双向转化策略包括持久化策略和反串形化策略， 以实现数据库中数据表的增删改查。 8.根据权利要求5所述的面向微服务的领域对象的低代码管理系统， 其特征在于， 所述 领域事件的定义用以描述领域实体 状态变更的发布和订阅关系配置 。 9.根据权利要求1所述的面向微服务的领域对象的低代码管理系统， 其特征在于， 所述 编译模块根据领域模型驱动的服务分层逻辑， 生成领域层的领域对 象类定义和关联图， 以 领域层为中心向外辐射生成基础层的持久化方案、 应用层的事件收发、 RPC调用组装机制、 以及接口层的外 部和RPC接口的实现。 10.根据权利要求9所述的面向微服务的领域对象的低代码管理系统， 其特征在于， 所 述编译模块封装 领域对象的生命周期管理、 持久化和加载、 查询检索、 RP C访问和交付、 领域 事件投递和订阅。权　利　要　求　书 1/1 页 2 CN 115543264 A 2面向微服务的领域对象的低代码管理系统 技术领域 [0001]本申请涉及应用程序自动发开技术领域， 尤其涉及一种面向微服务的领域对象的 低代码管理系统。 背景技术 [0002]由于微服务架构可以将复杂的业务逻辑， 拆解建模在一系列强内聚、 低耦合的微 服务中， 可以有效控制业务设计实施的复杂度， 已经成为当前互联网业务应用实现的主流 方案。 但伴随业务的反复迭代和功能扩展， 也会带来一下愈发严重问题， 使得业务 维护和研 发难以高效推进： [0003]1.业务研发中为描述业务对象会定义大量领域模型， 由于微服务对业务链路的分 散治理， 对同一业务对象极容易产生大量属性、 约束不一致的模型版本。 这些版本会泛滥在 调用链路的上 下游和不同业 务模块中， 给业 务维护和扩展带来巨大成本(图1)。 [0004]2.微服务中服务提供方定义的业务模型， 在新功能扩展时， 往往不能快速满足业 务需求。 这些模型， 或是缺少必要的属性需要额外组装； 或是已经过分庞杂， 存在大量调用 方不需要的属性。 如不有效控制， 研发人员会频繁变动被调用服务， 扩展 大量模型定义和服 务入口， 为持续维护业 务带来困难。 [0005]3.研发工作中有很大比重用于处理非业务逻辑。 由于服务实现中维护大量的业务 模型， 加之微服务研发中分层(接口层、 服务层、 持久化层)的最佳实践， 研发人员需要编写 大量代码用于： [0006]1)业务对象的领域模型(DO)、 展示模型(VO)和持久化模型(PO)的双向转化， 已经 各层间查询参数对象的转 化流程。 [0007]2)接口层和服 务层之间服 务入口的映射 [0008]3)服务层业务对象持久化逻辑和持久化层数据库访问的映射 [0009]4)服务层中外 部领域对象访问和远程RPC服 务的调用和组装映射。 [0010]这部分工作的代码和业务逻辑混杂在一起， 让研发人员无法集中关注核心业务价 值。 [0011]4.完整的领域模型在多次迭代后愈发碎裂， 产品和技术对全业务领域只能盲人摸 象。 现有的软件版本迭代流程中， 产品在PRD中输出了业务对象的领域模型图， 开发人员根 据PRD中的模型定义， 构建ER持久化模型， 实现业务对象的持久化方案。 多个版本的迭代以 后， 产品的领域模型是分散在各个版本PRD  中的 「子领域图」 ； 开发人员代码描述的业务持 久化模型能分散在各个微服务的代码片段中。 团队中的任何一方都很难快速从现有工作中 恢复出一张 「完整」 的业务领域模型图出来。 在遇到需要对现有业务逻辑进行迭代和优化 时， 评估其影响方案变成一个非常困难的工作。 发明内容 [0012]为了解决上述技术问题， 本申请实施例提供一种面向微服务的领域对象的低代码说　明　书 1/6 页 3 CN 115543264 A 3