- 博客(123)
- 收藏
- 关注
RSS订阅原创 【iSAQB软件架构】复杂系统架构描述的推荐实践
无论架构是明确形成还是隐性形成，如果没有被记录下来，其作用都是有限的。只有经过适当记录的架构才能持续地被交流、讨论和进一步发展。软件架构不仅要与其他架构师讨论。软件架构的所有方面都要向不同利益代表（利益相关者）展示、与他们讨论，并共同进一步发展。例如，客户和用户也可以参与影响他们的架构决策。开发人员也应该参与讨论，特别是对于与最终实现相关的架构方面的交流和讨论。
2025-06-09 10:48:57
199
原创 【iSAQB软件架构】构建块、接口
摘要：构建模块是软件架构的基本元素，包含从函数到子系统等不同层级的抽象组件，具有接口保证、封装可替换及分层配置三大特征。接口是系统的明确访问点，需详细定义语法、行为等特性，可分为标准接口、提供接口、所需接口和独立接口四种类型，分别由行业标准、组件提供者、使用者或架构师定义。标准接口确保互操作性，提供接口暴露模块能力，所需接口声明依赖，独立接口实现解耦。ISAQB框架强调分层协作，通过责任分离保障接口的稳定性和扩展性，是构建可持续架构的关键实践。（150字）
2025-06-06 15:02:49
628
原创 【iSAQB软件架构】魔法成功软件项目的矩形
在有限的资源和能力下，于 Effort（投入/成本）、Time（时间）、Functionality（范围）、Quality（质量）这四个相互关联、相互制约的维度之间，进行持续的、艰难的权衡与平衡。成功没有魔法公式，关键在于：清晰理解项目的核心固定约束（通常是时间或预算）。聚焦核心价值和 MVP。采用敏捷迭代方法，小步快跑，快速调整。建立并执行严格的变更管理。优化团队效率，将质量融入开发全过程。保持信息透明，主动管理期望和风险。
2025-06-06 14:47:56
904
原创 【iSAQB软件架构】软件架构定性评估和定量评估
软件架构评估：定性方法与定量方法的协同分析 在ISAQB框架下，软件架构评估包含定性评估（主观经验、专家判断）和定量评估（数据指标）。定性方法通过专家评审、场景分析等评估架构设计合理性，聚焦质量属性如可维护性、安全性；定量方法则通过静态分析、运行时监控等提供客观指标（如耦合度、性能数据）。二者协同作用：定性分析揭示设计意图与风险，定量数据验证问题严重性，共同指导架构优化决策。ISAQB分层评估模型（基础层定性为主，高级层引入量化）强调在早期设计阶段优先定性评估，后期结合定量跟踪演进效果，形成闭环优化。
2025-06-06 11:32:51
817
原创 【iSAQB软件架构】软件架构中构建块的视图：黑箱、灰箱和白箱及其交互机制
软件架构视图层级解析：黑箱、灰箱与白箱视图的区别与应用 本文系统阐述了软件架构设计中三种核心视图的差异与联系。黑箱视图聚焦模块外部行为，适用于需求分析阶段；灰箱视图揭示关键内部结构，用于详细设计；白箱视图则暴露完整实现细节，指导具体开发。三种视图呈现信息密度递增，分别服务于不同受众（业务方/架构师/开发者）。文章通过支付服务的具体案例，展示了各视图的表达方式与适用场景，并强调视图间的演进关系与隔离原则。最后指出架构师应灵活切换视图层级，确保技术细节的恰当披露与架构一致性维护。
2025-06-05 15:01:34
1139
原创 【iSAQB软件架构】如何理解架构模式中的管道和过滤器
管道和过滤器是一种经典架构模式，适用于需要将数据处理分解为独立步骤的系统。其核心是通过标准化接口连接无状态过滤器（处理单元）和管道（数据传输通道），形成可重组的数据流。典型应用包括ETL系统、编译器、命令行工具链等。优势在于高复用性、解耦和并行化能力，但也面临数据格式僵化、性能瓶颈等局限。现代实践中常结合消息队列增强解耦，或在流处理框架（如Flink）中实现。该模式最适合异步数据转换场景，而不适用于需要低延迟交互或复杂事务的系统。决策时需评估系统是否以数据流处理为核心需求。
2025-06-05 13:59:01
624
原创 【iSAQB软件架构】如何理解上下文视图
摘要： ISAQB框架中的上下文视图分为业务上下文和技术上下文。业务上下文关注系统在业务生态中的定位、价值流和角色交互，主要面向业务人员，输出业务流程图等；技术上下文则聚焦技术组件、协议和基础设施依赖，面向开发运维团队，输出系统集成图等。两者需严格分离但双向追溯，业务变更需评估技术影响，技术升级需验证业务兼容性。核心区别在于业务上下文解决“为谁提供什么价值”（Who-What-Why），技术上下文解决“如何协作实现”（How），共同构成完整的系统上下文视图。
2025-06-05 13:58:18
458
原创 【iSAQB大纲解读】管理构建块（Building Blocks）之间的依赖关系 (R1)
LG 2-7：管理构建块（Building Blocks）之间的依赖关系 (R1)软件架构师理解构建块之间的依赖关系和耦合，并可以有针对性地使用它们。根据ISAQB能力等级2-7（管理构建块依赖关系）的要求，软件架构师需掌握依赖关系的类型、影响及解耦策略。new B()🔥：电商系统若采用结算服务与库存服务，库存服务故障将直接导致结算服务不可用（连锁故障）。
2025-06-04 11:25:10
1112
原创 【ISAQB大纲解读】LG 1-10：区分IT系统类型（R3）
软件架构师需掌握七大IT系统类型及其关键特征：1)信息系统侧重数据管理与流程自动化；2)决策支持系统聚焦数据分析与OLAP架构；3)移动系统强调跨端体验与离线能力；4)云原生系统实现弹性伸缩与持续交付；5)批处理系统优化海量数据吞吐量；6)AI系统需数据版本控制与模型服务化；7)硬件系统要求μs级实时响应与软硬协同设计。架构决策需基于系统本质差异选择技术栈，权衡质量属性（如安全/性能/吞吐量），并匹配团队技能组合。理解系统类型是技术选型与架构模式选择的基础前提。
2025-06-04 11:23:27
602
原创 【ISAQB大纲解读】LG 1-8：区分显性陈述和隐性假设（R1）
摘要： 软件架构师需显式管理假设以规避风险。隐性假设（如未声明性能阈值或团队能力）易导致技术债务与系统故障，应在架构文档、决策记录中明确标注技术约束、资源需求等关键前提。通过术语统一、多视角验证及假设跟踪矩阵（含失效应对方案）消除利益相关方误解，并用可视化工具、自动化测试持续校验假设。核心原则是将假设转化为可验证、可溯源的公开约束，而非试图消除假设。（149字） 关键点覆盖： 显式化假设的必要性（防故障/技术债务） 实践方法（ADR、术语表、跟踪矩阵） 验证手段（原型、混沌工程） 最终目标（管理而非消除假设
2025-06-03 11:56:33
485
原创 【ISAQB大纲解读】Kafka消息总线被视为“自下而上设计”？
已有Kafka集群闲置容量30%，不如让新服务直接用它，省去新中间件采购成本”出发 → 抽象为通用能力 → 反推架构重构。：Kafka的诞生源于。
2025-06-03 11:48:24
946
原创 【ISAQB大纲解读】信息隐藏指的是什么
信息隐藏是软件架构的关键设计原则，由David Parnas提出，强调通过限制对模块内部细节的访问来降低系统复杂度。其核心是将"做什么"(接口)与"如何做"(实现)分离，使用封装、接口定义等技术手段实现。该原则能显著提升系统的可维护性、可扩展性和并行开发效率，是ISAQB认证架构师必备的核心能力。遵循信息隐藏的设计可使系统更灵活应对变更，保持模块间的低耦合和高内聚。
2025-06-02 15:38:54
1021
原创 【ISAQB大纲解读】- 横切概念指的是什么
它们之所以被称为“横切”，是因为它们不像核心业务功能那样通常被封装在特定的模块内，而是像一把刀一样“横向切过”系统的主要分层或功能划分。软件架构师的核心职责之一是管理复杂性并确保系统质量属性（非功能性需求）。在软件架构的语境下，特别是参考ISAQB（国际软件架构认证委员会）的学习目标，掌握识别和处理横切概念的能力是区分一个优秀软件架构师的关键。
2025-06-02 13:11:42
246
原创 职场中，如何锻炼向上管理能力
如果沿用旧架构，618大促时系统崩溃风险超过80%，预计损失销售额2000万+；你的任务不是教他写代码，而是设计一套「用户体验流程」，让他感觉一切尽在掌握，同时把专业决策权留在自己手中。“要实现这个功能需要申请XX云的GPU服务器，预算增加8万，您看是否需要协调财务特批？“这个方案会导致用户信用卡信息泄露，如果执行我需要书面确认风险自担”“上次腾讯的案例就是因为这个漏洞导致数据泄露，罚款500万”“按您的要求采用B方案，已记录风险：1.XXX 2.XXX”“这个架构必须用微服务，单体架构扛不住并发”
2025-05-30 09:55:18
751
原创 【产品经理从0到1】平台端产品设计
本文主要探讨平台端产品设计，涵盖用户管理、内容运营与监管功能规划。在用户管理方面，详细设计了普通用户、自媒体用户的分类管理及审核流程，并引入马甲账号机制用于社区运营。内容管理部分包含文章发布审核、频道分类、敏感词过滤和标签系统。运营管理模块涉及消息推送、权限分配及操作日志追踪功能，确保责任可追溯。最后提出数据统计方案，包括用户活跃度、访问趋势等核心指标监控。整套设计注重平台内容质量管控与运营效率提升，通过系统化工具实现用户留存与内容生态平衡。
2025-05-30 09:52:01
1175
原创 【产品经理从0到1】自媒体端产品设计
后台” 与“前台”都是相对独立的平台，前台是服务于互联网用户的平台 ，后台主要是支撑前台页面内容、数据及对前台业务情况的统计分析的系统；手机端发布图文确实很不方便，为了优化用户体验，鼓励用户发布优质文章，需要提供一个Web端发布环境，这个发布环境，一般称为自媒体端。
2025-05-29 11:14:42
1109
原创 SpringBoot的java应用中，慢sql会导致CPU暴增吗
在 Spring Boot 应用中，慢 SQL 既可能导致数据库服务器 CPU 暴增，也会间接引发应用服务器 CPU 升高（线程阻塞、结果集处理、连接池耗尽）。，同时需结合限流、异步化、缓存等综合手段降低对 CPU 的影响。建议通过监控工具准确定位瓶颈，避免盲目扩容硬件。是的，在 Spring Boot 的 Java 应用中，虽然 SQL 执行主要在数据库端，但以下场景会导致。慢 SQL 在数据库层面会直接导致。，这是最直接的影响。
2025-05-28 14:09:43
808
原创 计算密集任务和IO密集任务之间的区别
通过区分任务类型，可更精准地分配系统资源（如CPU核心绑定、磁盘优先级调度），避免资源争用导致的性能瓶颈。异步流水线：I/O阶段用NIO读取文件 → 提交计算任务到专用队列 → 结果异步返回。使用独立线程池隔离两类任务（如计算任务用固定大小池，I/O任务用弹性池）。计算密集型任务 vs. I/O密集型任务。
2025-05-27 12:02:27
170
原创 Java应用中 慢SQL导致内存无法回收，然后导致线程阻塞，CPU被撑爆
bash# 增加老年代空间，减少Full GC频率-XX:NewRatio=2 -XX:+UseG1GC # 对高延迟场景更友好-XX:MaxGCPauseMillis=200 # 目标暂停时间5. 熔断降级。使用 jmap 生成堆转储文件，通过MAT工具分析大对象或未释放的数据库资源：bashjmap -dump:live,format=b,file=heap_dump.hprof。GC压力：频繁Full GC尝试回收内存失败，导致GC线程占用CPU资源。
2025-05-27 11:56:41
789
原创 【产品经理从0到1】用户端产品设计与用户画像
动态标签是动态的，它是根据用户的操作行为给用户打上不同的行为标签，通过获取到大量的网络行为数据、网站行为数据、用户内容偏好数据、用户交易数据。回想一下，大家在第一次使用一个新下载的App的时候会看到一些什么样的页面?主要用于做一些开机的广告，可以是品牌的宣传，可以是商品的宣传，也可以是各种活动的宣传等等。8.如此，随着用户的行为数据的积累，用户标签的权重值就会出现阶梯，画像即形成。
2025-05-20 15:27:14
790
原创 React和Vue在前端开发中， 通常选择哪一个
如果你需要一个更灵活、能通过组合多个库和工具来实现自定义需求的框架，React 是一个不错的选择。如果你更倾向于易学易用、开发周期短，并且希望框架本身提供更多功能，Vue 可能更合适。根据你的项目需求和团队的技术栈选择合适的框架吧！如果是个人项目或快速开发，Vue 可能会更容易上手；如果是大型团队或长周期开发，React 的生态系统和灵活性可能更合适。
2025-05-15 18:21:56
499
原创 产品PRD中一般需要包含哪些内容，必须要有产品概述和需求池吗
结论：产品概述和需求清单是PRD的必要内容，而“需求池”属于长期需求管理工具，无需写入PRD。需求池（Product Backlog）：长期需求集合，优先级动态调整，独立于PRD管理。作用：明确产品背景、目标用户、核心价值、业务目标（如转化率提升、用户增长等）。内容：当前版本需实现的需求列表（含优先级、功能描述、验收标准等）。注意：需求池（长期需求列表）通常独立维护，不属于PRD强制内容。内容：具体功能逻辑、交互流程、原型图/UI标注、埋点规则等。需求清单：仅包含当前版本需开发的需求，是PRD的必要内容。
2025-05-14 14:24:07
202
原创 【LLM模型】如何构建自己的MCP Client？
开始构建可以与所有 MCP 服务器集成的自己的客户端。在本教程中，您将学习如何构建一个基于 LLM 的聊天机器人客户端，并连接到 MCP 服务器。如果您已经阅读过服务器快速入门指南，它将指导您完成构建第一个服务器的基础知识。
2025-05-14 10:39:34
1095
原创 【数据库】数据库设计中，关系描述 和 外键存储
关系类型关系描述外键存储位置1对1两个实体之间有一对一的关系外键可以存储在任一方的表中1对多一个实体实例与多个实体实例之间有关系外键存储在“多方”表中，指向“1方”表多对多两个实体实例之间有多对多的关系使用中介表，存储两个外键分别指向两个实体表。
2025-05-13 16:43:51
916
原创 【LLM模型】如何构建自己的MCP Server？
Model Context Protocol (MCP) 是一种协议，它允许大型语言模型（LLMs）访问自定义的工具和服务。Trae 中的智能体作为 MCP 客户端可以选择向 MCP Server 发起请求，以使用它们提供的工具。你可以自行添加 MCP Server，并添加到自定义的智能体中来使用。MCP 是一个开放协议，它规范了应用程序向 LLM 提供上下文的方式。MCP 就像 AI 应用程序的 USB-C 端口一样。
2025-05-13 16:38:43
984
原创 【产品经理从0到1】后台基础
我们搭建了一个xx资讯的前台MVP产品，允许用户在前台发送各种原创内容。但内容的总量还是不够，需要支持让公司的运营人员在系统中发送文章，请问该怎么做？答：搭建后台管理系统，添加内容管理模块等；“后台” 与“前台”都是相对独立的平台：• 前台是服务于互联网用户的平台；• 后台主要是支撑前台页面内容、数据及对前台业务情况的统计分析的系统。
2025-05-08 11:59:24
866
原创 【产品经理】常见的三大后台系统
企业可根据自身规模（中小型企业可能先上OA/CRM，大型企业优先ERP）和行业特性（如制造业重ERP，服务业重CRM）分阶段部署这些系统。通过集成企业内部核心业务流程（如财务、供应链、生产、人力资源等），实现数据共享与流程协同的系统，目标是优化资源配置、提升运营效率。数据互通：CRM的客户数据可同步至ERP生成销售订单，OA审批的采购单自动触发ERP库存更新。ERP侧重后端资源管理，CRM聚焦前端客户价值，OA连接全员协作。例如：销售通过CRM签单→ERP安排生产→OA协调物流与财务结算。
2025-05-08 11:11:31
325
原创 【产品经理】互联网产品开发思路
在互联网产品开发中，选择公众号/服务号、小程序、APP的顺序需要结合业务场景、资源投入、用户需求和长期战略来综合决策。低成本验证：开发周期短（1-2周），成本仅为H5页面开发，适合快速测试核心功能（如信息推送、表单收集）用户触达效率：消息模板可直接触达用户，图文推送打开率高于APP推送（平均18% vs 5%）生态流量优势：通过微信搜索、朋友圈分享获取自然流量，适合内容型产品（知识付费、媒体类）O2O服务未利用服务号模板消息（订单提醒打开率下降60%）工具类产品过早开发APP（日活<1万时投入百万开发）
2025-04-27 12:57:38
321
原创 【产品经理从0到1】产品设计规范下
小程序：一种不需要下载安装，即可使用的应用；开发成本低；流畅的使用体验；庞大的流量池可供使用；用完即走，不占用手机内存，但是有使用记录供用户可方便的再次找回产品；导航设计要遵循以下原则：• 简单：每个网站都应该有尽可能简单的结构；• 清晰：导航的每项对用户而言，都应该是清楚的；• 一致：系统的导航页在每一页中都应该是相同的；• 用户最少的点击，最快地到达目的网页；PC导航：面包屑，非线性；APP导航：线性；
2025-04-27 12:10:28
808
原创 【产品经理】常见的交互说明撰写方法
若验证通过，跳转至成功页。方法：制作可交互的高保真原型（如ProtoPie、Principle），通过动效模拟操作流程。“表单提交时若网络断开，显示Toast提示‘网络异常，请重试’，并在3秒后自动重新提交。通过组合上述方法，您可以清晰传达设计意图，降低开发理解成本，确保产品交互逻辑的准确实现。方法：直接在原型图（如Figma、Axure）中添加注释，说明元素的交互行为。方法：描述界面或组件的不同状态（如默认态、加载态、报错态）及触发条件。适用场景：多分支、复杂流程（如注册登录、支付流程）。
2025-04-25 16:16:55
440
原创 【产品经理从0到1】产品设计规范上
• 原型要先画默认状态（没有任何操作之前的状态），然后再绘制交互后的效果；• 产品经理在设计交互逻辑时，为了避免让用户陷入更深层级中，一般要求单流程最多跳三次（特殊情况除外），常见的临时视图不占次数；• 在设计强制执行页面时（如强制注册）一般不提供其他跳转出口，让用户保持高度专注，形成逻辑闭环，减少错误发生；（慎用）• 弱执行流程（比如浏览、查看详情等）可提供跳转出口（如分享），增加流量；• 完成阶段一般可以设置快速返回，让用户更快从深层返回。
2025-04-25 16:05:04
1129
原创 【产品经理从0到1】Axure介绍
addMilliseconds：返回一个新的DateTime，它将指定的毫秒加到此实例的值上。addMinutes：返回一个新的DateTime，它将指定的分钟数加到此实例的值上。addMonths：返回一个新的DateTime，它将指定的月数加到此实例的值上。addHours：返回一个新的DateTime，它将指定的小时数加到此实例的值上。addYears：返回一个新的DateTime，它将指定的年数加到此实例的值上。addDays：返回一个新的DateTime，它将指定的天数加到此实例的值上。
2025-04-24 12:56:53
708
原创 【产品经理从0到1】原型及Axure介绍
功能：用于快速制作原型的软件，它在无需编码的情况下构建低、高保真的原型，只需拖、拉、编辑即可完成；原型：用线条、图形描绘出的产品框架，也称线框图，是需求和功能的具体化表象；作用：1、原型是需求和功能的具体化表象，可以辅助产品经理与领导、UI、和技术进行沟通；2、原型相对于手稿而言，信息含量更丰富。选择、置顶、组合选择：建议⼤家使⽤“包含选中”，这样可以避免误操作；缩⼩/放⼤：⼤家在制作原型的时候，这两个功能要经常使⽤，提升原型制作效率；
2025-04-24 11:44:09
1151
原创 【产品经理从0到1】产品规划
• 包含关系，可以纵向进行信息架构，比如买东西的时候，挑选、下单、支付、邮寄之间就是上下游包含的关系，要邮寄必须得先支付，要支付必须先下单，要下单先要经过挑选；• 并列关系，两个功能之间没有关联，可以考虑横向进行信息架构，比如微信里面的通讯录和发现，两个功能之间相互影响的因素很小。来描述业务流程的一种图，通过一些特定的符号和连线来表示具体某个业务的实际处理步骤和过程，详细地描述任务的流程走向。• 产品从0到1，从1到N，是一步一步来的，产品功能也是不断增加完善的；反映在数据流程图中。
2025-04-23 14:01:32
1417
原创 【产品经理】业务流程图需要画到多细才算合格？
合格流程图：包含分支逻辑（如支付成功/失败）、系统自动触发的动作（如库存扣减）、人工介入环节（如大额订单风控审核）。不合格流程图：仅描述“用户下单→支付→发货”，未说明支付失败如何重试、库存不足时如何通知用户。如果某个步骤存在超过20%概率的异常情况（如支付失败、审核驳回），需要单独标注处理流程。具体执行（给开发、操作人员用）：需细化到操作步骤、异常处理、数据流向等。必须包含所有影响业务结果的核心步骤（例如订单生成、支付、审核、退款）。流程图需标注参与角色（用户、系统、部门），并明确各环节的责任归属。
2025-04-23 13:52:46
334
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人