重构过之后,编辑,新增订单可以公用一套代码,直接调用对应的方法就行了,即使增加一个查看框,也用不了太久就能搞定,之前的方式就是代码copy,没有抽出业务公共的逻辑。 jquery系列的老的产品代码,最好的重构方法就是插件化,现代三大框架,vue,react,angular,就是组件化,加上,数据状态管理器搞定。
今天我们谈一谈如何使用DDD重构中台业务。 DDD有两把利器,那就是它的战略设计和战术设计方法。中台在企业架构上更多偏向业务模型,形成中台的过程实际上也是业务领域不断细分的过程。 在这个过程中我们会将同类通用的业务能力进行聚合和业务重构,再根据限界上下文和业务内聚的原则建立领域模型。而DDD的战略设计最擅长的就是领域建模。 这个过程会沉淀公共和复用的业务能力,会将分散的业务模型整合。自底向上策略适用于遗留系统业务模型的演进式重构。 最终个人客户的领域模型重构为: 个人、归并和视图三个聚合重构为个人领域模型(客户信息管理),评级和积分两个聚合重构为评级积分领域模型(面向个人客户)。到这里我们就完成了个人客户领域模型的构建了。 重构过程中的领域对象 上面主要是从聚合的角度来描述中台业务模型的重组,是相对高阶的业务模块的重构。业务模型重构和聚合重组,往往会带来领域对象和业务行为的变化。
重构,于我而言,很大的快乐在于能够解决问题。 第一次重构是重构一个c#版本的彩票算奖系统。当时的算奖系统在开奖后,算奖经常超时,导致用户经常投诉。 Feed(动态):Feed流中的每一条状态或者消息都是Feed,比如朋友圈中的一个状态就是一个Feed,微博中的一条微博就是一个Feed。Feed流:持续更新并呈现给用户内容的信息流。 每个人的朋友圈,微博关注页等等都是一个Feed流。 家校朋友圈是校信app的一个子功能。学生和老师可以发送图片,视频,声音等动态信息,学生和老师可以查看班级下的动态聚合。 为什么要重构呢? 重构过程 《重构:改善既有代码的设计》这本书重点强调: “不要为了重构而重构”。重构要考虑时间(2个月),人力成本(3人),需要解决核心问题。 1、功能模块化, 便于扩展和维护 2、灵活扩展Feed类型, 支撑新业务接入 3、优化动态聚合页响应速度 基于以上目标, 我和小伙伴按照如下的工作。
优化设计:根据重构目标,对系统的设计进行优化。这可能包括解耦各个模块、引入新的设计模式、重构数据库结构等。 重构代码:根据重构目标和优化设计,逐步重构系统的代码。 持续集成和部署:在重构完成后,要进行持续集成和部署,确保重构后的系统能够正常运行并且满足业务需求。 监测和优化:一旦重构完成,要对系统进行监测和优化,及时发现和修复可能存在的问题,并持续优化系统的性能和功能。 以下是一个案例Java业务系统的分析、案例分析和代码。 业务系统分析 在这个业务系统中,我们假设有一个电商平台,需要实现以下功能: 用户注册和登录:用户可以通过注册功能创建新的账户,然后使用登录功能进行身份验证。 可以根据需要扩展和修改代码,以满足具体业务需求。 以上是快速重构系统的一般步骤,具体的重构过程可能根据系统的实际情况而有所不同。
锚定确定性价值,重构企业健康发展逻辑 在快速变化的商业环境下,传统企业面临着战略演进与业务升维的双重挑战,亟需一套系统的破局逻辑,以实现增长底层方法论与治理体系的同频共振。 核心业务节点切入: 深入剖析企业全业务价值流,放弃在标准合同履行等后端环节发力,精准切入“市场洞察与销售拓展”阶段,锁定“初次接触的客户场景”下的“提供解决方案”这一高价值节点。 闭环AI方案助手工作流: 需求理解: 针对战略、组织、人才与生态四个维度进行深度的需求拆解。 设计方案: 自动生成基础方案框架,并匹配后续交付与运营保障要求。 通过腾讯云TI平台内置的模型工具链(涵盖提示词优化、专有知识库搭建与复杂工作流编排),企业能够将非结构化的咨询经验快速转化为可执行的模型指令。 在保障系统高稳定性与低运维成本 (Ops Cost) 的前提下,解放了业务团队的开发精力,使其能够完全聚焦于“业务规则定义”与“高质量数据反哺”,真正实现了基于业务流底层逻辑重构的数字化跃升。
重构,是任何一个技术团队都无法绕过和回避的话题。 重构的原因有很多,可能是伴随着业务的发展与升级,系统无法快速支持需求迭代,这时就有了重构的念头,一般情况下不建议对老系统进行重构,毕竟重构是有代价的。 我最近参与了一个重构项目,接下来给大家分享下,我在重构业务系统过程中的经验总结。 1. 了解系统 接到重构任务后,不要立刻动手执行重构,而是对当前的业务流程和架构状态有个清晰的了解,如果开发过当前系统的同事还在公司,一定要拉着同事好好讨论。 我们要知道系统一定是给人用的,是给哪些人用的? 业务功能模块图 根据业务流程图、业务各分支流程图,我们要确定出哪些功能模块?各功能模块之间是如何交互的?原来数据是如何存储的?
作为后端架构师,我意识到必须将“基于特征定位”的逻辑彻底重构为“基于语义理解”的动态解析架构。 二、架构重构与数据流设计为了解决UI动态性带来的脆弱性,我们决定在执行层之上引入一层“视觉语义解析层(VisualSemanticLayer)”。 以下是我们重构后的技术链路流程:展开代码语言:TXTAI代码解释flowchartLRA[屏幕实时流采集]-->B[视觉特征提取(CV)]B-->C{动态语义解析引擎}C-->|匹配业务意图|D[操作指令序列生成 为此,我们在重构代码时,集成了一个高性能的本地SDK。以下是我们在核心逻辑层调用实在Agent(作为底层视觉解析库)实现动态定位的Python伪代码。 ,device="cuda",vision_mode=True)self.context=task_contextdefexecute_step(self,intent:str):"""intent:业务意图
1.什么是工作流审批 根据本人的理解,就是审批流程管理。 2.什么是flowable 1.官方解释 官方解释如下: Flowable 项目提供了一套核心的开源业务流程引擎,这些引擎紧凑且高效。 它们为开发人员、系统管理员和业务用户提供工作流和业务流程管理 (BPM) 平台。 这里总结一下: 目的是管理业务审批工作流。 使用BPMN技术。 可方便嵌套在spring体系中。 此外,图形符号将有助于理解组织之间的绩效协作和业务交易。这将确保企业了解自身和业务参与者,并使组织能够快速适应新的内部和 B2B 业务环境。 5.通用的业务流程 标准的审批流系统都有一套标准化的业务流程下文,介绍如何操作审批流系统。 1.整体流程 业务流程主要分以下步骤: 一般在系统中的模块名如下,请各自对应。
一线负责过传统软件公司ToB类和互联网公司ToC类的业务系统,理解体会过其中的相同与不同,擅长利用DDD和OO思想对业务需求进行分析建模与设计开发。 倘若说领域驱动设计难,我认为其中的症结是没有打通业务与开发沟通的桥梁,各自为政,导致开发对业务傻傻不了解,业务对开发则怨言满满。 机缘巧合,不久前的工作内容中,需要把之前分散在若干个业务系统中(微服务)的购买相关功能进行梳理重构,在这个重构的过程中,充分运用了领域驱动设计中战略设计部分的思想,达成了目标。 订单化系统不能完全解决业务的问题 分析业务规则并读了一些代码后,整理出了订单化系统的一些分析和设计文档,经过了团队内部确认理解正确,找业务方在沟通一下就可以开工了。 对业务上下文和限界的理解不足,很容易切换到以用户为中心去建立领域模型的心流模式。
1.应对业务扩张带来的IT系统复杂性随着美的集团在欧洲业务的持续增长,其IT系统面临着多重挑战。为了支撑欧洲业务的创新发展,美的亟需构建一个能够平衡安全合规、稳定灵活与高性价比的云平台。 核心痛点在于如何处理原有的接近50个独立业务系统,解决系统分散带来的管理难题,并满足欧洲市场严格的本地化合规要求。 2.统纳近50个独立系统至云原生架构针对上述挑战,美的集团选择将欧洲IT业务迁移至腾讯云,实施了深度的技术底座重构:●基础设施迁移:基于腾讯云位于欧洲法兰克福的数据中心,构建全新的技术底座,确保数据合规与本地化服务能力 ●架构标准化:将原有的接近50个独立业务系统统一纳入标准化的云原生架构。●技术栈重构:对公共组件技术栈进行全面重构,并利用云原生技术实现业务系统的容器化升级。 3.达成成本优化与系统稳定性提升通过此次“搬迁”与架构升级,美的集团在欧洲市场的IT运营取得了实质性的量化成效:●运营效率:业务后台架构更加清晰,运营效率显著提升。
一线负责过传统软件公司ToB类和互联网公司ToC类的业务系统,理解体会过其中的相同与不同,擅长利用DDD和OO思想对业务需求进行分析建模与设计开发。 倘若说领域驱动设计难,我认为其中的症结是没有打通业务与开发沟通的桥梁,各自为政,导致开发对业务傻傻不了解,业务对开发则怨言满满。 机缘巧合,不久前的工作内容中,需要把之前分散在若干个业务系统中(微服务)的购买相关功能进行梳理重构,在这个重构的过程中,充分运用了领域驱动设计中战略设计部分的思想,达成了目标。 订单化系统不能完全解决业务的问题 分析业务规则并读了一些代码后,整理出了订单化系统的一些分析和设计文档,经过了团队内部确认理解正确,找业务方在沟通一下就可以开工了。 对业务上下文和限界的理解不足,很容易切换到以用户为中心去建立领域模型的心流模式。
核心要求是程序员明确知道 “怎么做”,通过手动编码实现功能 2、Vibe Coding:以需求描述为核心 Vibe Coding 是一种依托 AI 能力的新型开发模式,核心逻辑高度聚焦: 用自然语言精准描述业务需求与工作流 2.2 AI 编程的缺点与挑战 1、天生缺乏业务场景深度理解 核心现象 AI 生成的代码,经常会陷入“技术正确,业务失真”的困境——语法合规、可编译运行,但完全不符合真实业务的约束条件与核心诉求。 典型案例:电影数据展示列表场景 AI 仅生成通用的电影数据列表展示代码,却忽略豆瓣Top250项目的核心业务规则: 业务中需按“评分降序、上映时间筛选”双维度排序展示电影 需实现分页加载(避免一次性加载 解决思路 由人明确定义不可让步的业务规则与约束条件,为 AI 划定业务边界。 三、如何正确理解重构工作流 个人对 [ vibecoding 加成下 ] 重构工作流的理解 AI 不是来当主厨的,是为了让主厨不用天天切土豆 3.1 构思全自动化工作流 关键原则:摒弃“一步到位”的完美主义
倘若说领域驱动设计难,我认为其中的症结是没有打通业务与开发沟通的桥梁,各自为政,导致开发对业务傻傻不了解,业务对开发则怨言满满。 机缘巧合,不久前的工作内容中,需要把之前分散在若干个业务系统中(微服务)的购买相关功能进行梳理重构,在这个重构的过程中,充分运用了领域驱动设计中战略设计部分的思想,达成了目标。 02 订单化系统不能完全解决业务的问题 分析业务规则并读了一些代码后,整理出了订单化系统的一些分析和设计文档,经过了团队内部确认理解正确,找业务方再沟通一下就可以开工了。 对业务上下文和限界的理解不足,很容易切换到以用户为中心去建立领域模型的心流模式。 06 总结 DDD 思想指导的开发过程,首先是开发团队要和领域专家去针对业务需求进行充分的讨论沟通,这一点很重要,业务线的开发人员有个不好的习惯:被动接受需求,回头再来抱怨业务人员或者产品经理没有表述清楚
一、场景法 通过运用场景来对系统的功能点或业务流程的描述,从而提高测试效果的一种方法。 场景法一般包含基本流和备用流,从一个流程开始,通过描述经过的路径来确定的过程,经过遍历所有的基本流和备用流来完成整个场景。 二、基本流和备用流 1、基本流(正确流):模拟用户正确的操作流程 目的:验证软件的业务流程和主要功能 2、备选流(错误流):模拟用户错误的操作流程 目的:验证软件的错误处理能力 ? 三、场景法的本质 1、场景法是一种基于等价类划分的测试技术(技术层面) 2、场景法的应用是基于对软件业务(需求)的深入理解(业务层面) 四、场景法的基本设计步骤 1、根据说明,描述出程序的基本流及各项备选流 2、根据基本流和各备选流生成不同的场景 3、对每一个场景生成相应的测试用例 五、使用场景法分析程序:ATM取款 1、根据需求,找到基本流和备选流(找出正确的操作流程和可能出错的环节)
企业领导者们增加支出并非因为感到乐观,而是因为业务流程已越来越多地运行在这些系统之上。 同时,报告指出,人工智能已走出试点项目阶段,进入核心业务运营。这使得这些系统越来越难以在不影响企业日常运营的情况下被剥离。这些问题并不局限于单个组织。 这些标准正越来越多地渗透到私营部门,无论企业是否与政府有业务往来。这些信号共同表明,技术正被用于承载那些企业因人力不足而无法依靠人工管理或执行的决策与流程。 企业正在将生成式AI作为日常业务的一部分。基于代理的系统正被部署到IT运营、软件开发和业务职能部门中。预计在未来几年内,智能体AI将占据AI支出中越来越大的份额。 现在的审视焦点在于领导者能够解释并捍卫的最终业务成果。对于CEO而言,焦点在于治理。董事会正迫切要求清晰地了解AI嵌入业务的准确位置,以及谁为这些系统现在所做出的决策负责。
当业务增长成为常态,客户咨询量指数级上升,大多数企业却还在用"堆人"的方式解决售后问题。这不是在解决问题,而是在制造一个更大的问题。 客户感受到的是"秒回"和"懂我",企业收获的是人效重构。 `bash-c"$(curl-fsSLhttps://release.baizhi.cloud/koala-qa/manager.sh)"`###2.越用越懂你的业务每次人机交互都被自动分析,优质对话实时转化为知识库资产 Step2:知识注入上传产品手册、历史工单、FAQ,AI自动解析业务语义。Step3:智能运营系统自动分流处理,后台生成问题热力图,反向驱动产品优化。 别让落后的售后模式,成为业务增长的隐形天花板。
工作流定义: The automation of a business process, in whole or part, during which documents, information or -工作流标准组织 业务流程管理:Adding Integration to the above definition. 也就是把把整合的概念加到上述工作流定义中。把系统、组织结构、程序整合到一起。 BPM的出现正是为了解决企业流程实时改变所带来的敏捷性、实时效果评估、资源整合与优化等问题,而这些问题是不能为传统的OA和工作流所解决的。 它可以进行工作协调与应用程序集成:大部分的企业流程并不只是运行单一业务功能,而是多个业务功能互相协调后的成果;因此,原本独立支持某项业务运作的应用系统,也必须跟其他业务的应用系统相互集成。
架构实践:翻译表分离 + 服务层装配 在多语言业务场景中,为现有业务实体(Product、Vehicle、RealEstate 等)增加国际化支持,核心矛盾在于:既要保留原有数据模型的稳定性,又要实现按语言动态返回字段值 架构设计思想:职责分离与解耦 核心理念在于将“业务逻辑”与“语言逻辑”完全剥离: 数据解耦:主业务表仅存储业务事实(默认值/标识),翻译内容完全剥离至独立表。 方案优势分析 ✅ 非侵入性:原有业务主表结构、历史数据、既有 SQL 完全无需改动。 ✅ 高扩展性:支持“即插即用”,新增实体类型只需添加分区和配置。 这种横向切分确保了核心业务模型的简洁与纯粹。 它不仅解决了多语言存储的难题,更提供了一套通用的、可扩展的业务实体增强框架,为系统的全球化运营奠定了坚实的架构底座。
,兼容性差,难以复用,开发周期长 • 效果不可控:AI 输出质量不稳定,缺乏有效的质量评估、审计追溯和修正机制,难以保证业务可靠性 • 成本不可控:API 调用费用随业务增长线性上升,缺乏智能缓存、请求优化等成本控制手段 运行时切换 - 支持在运行时根据业务需要使用不同的LLM配置 3. 使用量、处理时间、成本(USD) • 状态跟踪: 成功状态、错误信息、重试次数、JSON修复标记 • 业务关联: 批次ID、父审计ID、业务实体ID/类型、数据量 2. • 低侵入性设计 业务上下文传递: • 支持设置业务场景、交互类型 • 支持批次关联和父子关联 • 支持业务实体关联 • 灵活的元数据扩展 应用价值 1. 业务系统集成 • PartnerSdk: 轻量级SDK,简化集成流程 • 业务内聚: AI伙伴实现在各自的业务系统中 • 独立演进: 各业务系统独立部署和升级 • 标准化接口: 统一的API和消息协议
第一章 突破物业经营瓶颈与流量困局 行业痛点:基础服务与多经业务的双重割裂 当前物业行业头部客户在探索多种经营(多经)商城零售业务时,普遍面临“低频消费、高运营成本、低转化率”的结构性矛盾,具体表现为四大核心痛点 管家效能与激励错位: 意愿低: 市场化零售并非管家主营核心业务,因激励不足、产品不好卖,导致终端推广积极性低。 分层激励体系: 针对不同业务周期设计商品激励、时间激励、渠道激励及会员激励等多维体系,确保管家在推广非主营业务时有足够的动力。 第三章 量化业务增量与降本成效 应用效果:数据驱动的业务价值验证 通过腾讯生态资源的注入与数字化工具的落地,多经业务在获客、转化与人效上均实现了显著提升: 流量与GMV爆发: 视频号DAU突破 5亿+,