<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[系统工程实验室]]></title><description><![CDATA[至于国内系统工程/软件工程/过程管理理论推广及能力提升！]]></description><link>https://blog.youkuaiyun.com/SystemEngineeringLab</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; SystemEngineeringLab]]></copyright><item><title><![CDATA[开放式架构之国产化替代的分层抽象]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/161363237</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/161363237</guid><author>SystemEngineeringLab</author><pubDate>Sun, 24 May 2026 12:43:55 +0800</pubDate><description><![CDATA[国产化替换暴露的，从来不是技术能力的问题，而是架构决策的时间差问题。适配层做的三件事，本质上是同一件事：控制权收回。把领域语言的定义权收回来，把替换决策的影响范围收回来，把供应商谈判的主动权收回来。]]></description><category></category></item><item><title><![CDATA[设计模式之外观模式]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146469645</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146469645</guid><author>SystemEngineeringLab</author><pubDate>Mon, 24 Mar 2025 10:28:44 +0800</pubDate><description><![CDATA[系统的通用设计目标是最小化子系统间的通信和依赖。实现该设计目标的一种方式是引入外观对象，为子系统中的通用设施提供一个单一并且简单的接口。与适配器模式区别本质上二者的模式意图不同：适配器是将接口转换为不同接口，外观模式是提供一个统一的接口来简化子系统的访问。基于外观模式，客户端请求首先到达外观类，并由外观类负责路由并委托到具体的子系统类处理逻辑。为子系统的接口集合提供一个统一接口，Facade定义高层接口使得子系统更容易使用。将客户单请求委派给合适的子系统对象。外观对象：Facade。]]></description><category></category></item><item><title><![CDATA[系统架构设计-防腐层、门面模式和适配器模式]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146469590</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146469590</guid><author>SystemEngineeringLab</author><pubDate>Mon, 24 Mar 2025 10:27:06 +0800</pubDate><description><![CDATA[门面模式和适配器模式是代码级的设计模式，而防腐层本质是一种防御型策略，在更高的层级对系统进行解耦。]]></description><category></category></item><item><title><![CDATA[系统架构书单推荐（二）：分析与建模]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146437475</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146437475</guid><author>SystemEngineeringLab</author><pubDate>Sat, 22 Mar 2025 11:57:05 +0800</pubDate><description><![CDATA[系统架构分析与建模经典书籍推荐]]></description><category></category></item><item><title><![CDATA[系统架构书单推荐（一）领域驱动设计与面向对象]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146437453</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146437453</guid><author>SystemEngineeringLab</author><pubDate>Sat, 22 Mar 2025 11:55:27 +0800</pubDate><description><![CDATA[想寻找 “到底什么是软件架构” 这一问题的答案，Mark Richards, Neal Ford 两位大师在该书中从自身视角对软件架构进行了定义说明，并详细描述的不同的应用架构风格及其多维度的指标分析。推荐理由：黑天鹅事件、《三体》中的射手和农场主假说......在混乱的表象之上，我们应该如何追本溯源、直达问题的本质，相信这本书能带给你一些醍醐灌顶的收获。：该书技术思想领域的开创性作品，归纳总结了技术的定义，详细解释了技术的进化机制，并且构建了一个完整的关于技术的理论体系。]]></description><category></category></item><item><title><![CDATA[业务概念模型，你必须知道的建模分析工具]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146426138</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146426138</guid><author>SystemEngineeringLab</author><pubDate>Fri, 21 Mar 2025 17:45:21 +0800</pubDate><description><![CDATA[对于概念模型我们并不陌生，其本质是模型，是对某个域信息的建模，例如常见的E-R图是对数据模型的建模。多数情况下，作为技术我们更多的接触的是技术域的分析与建模。业务概念模型（Business Conceptual Model）是一种用于描述业务领域核心概念及其关系的工具，业务概念模型的本质在于语言对齐（或统一语言）。它通过定义业务术语及其关系，建立业务团队与技术团队之间的共同语言，确保双方对业务需求的理解一致。业务概念模型是技术无关的，其不涉及技术实现细节，而是专注于业务域逻辑的抽象与表达。]]></description><category></category></item><item><title><![CDATA[软件架构图评审检查单]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146426088</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146426088</guid><author>SystemEngineeringLab</author><pubDate>Fri, 21 Mar 2025 17:43:06 +0800</pubDate><description><![CDATA[设计意图的传达是架构可视化关注的重要维度，在技术方案评审过程中不可避免的会出现各种各样的架构图或设计图，这些图形化表述在设计设计意图传达效果层面表现不一。不论架构设计者，还是参与设计评审的开发人员，对于形式各异的 “架构图” 是提供通用的参考关注点，以便干系人。是否能够理解架构图中每个元素的类型？是否能够理解架构图中的每个关联关系（适合标明技术选型的场景）的。是否能够理解架构图中的每个元素是做什么的？是否能够理解架构图中的关联关系的简称或缩写？(比如，进程间的交互的协议)是否能够理解架构图中元素使用的。]]></description><category></category></item><item><title><![CDATA[代码评审的参考规范]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146426020</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146426020</guid><author>SystemEngineeringLab</author><pubDate>Fri, 21 Mar 2025 17:39:55 +0800</pubDate><description><![CDATA[不要惧怕提出问题，这更容易提高你对问题的认知，如果最终发现你提出的问题是错误的，这对你也是一项难得的提高。不要为了提高评审速度而牺牲代码评审的标准，团队内的代码评审应该是一个持续改进的过程，发现问题、解决问题、避免问题，这种正向循环会为研发流程的每一步都带来收益。代码评审的目的就是为了保证公司整体代码的健康状况随着不断迭代，始终保持一个较高的水平，所有在评审中使用的工具和流程都应是为此目的而设计的。如果评审尺度严格导致研发人员抱怨，那么礼貌的坚持非常有必要，严格的代码评审有助于产出优秀的代码。]]></description><category></category></item><item><title><![CDATA[分层单体应用架构的本质]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146425721</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146425721</guid><author>SystemEngineeringLab</author><pubDate>Fri, 21 Mar 2025 17:28:38 +0800</pubDate><description><![CDATA[良好的模块化是单体走向微服务的重要基石，如果模块化设计较差的系统，不仅会增加微服务拆分的成本，更为重要的是，会增加拆分后形成分布式单体的概率和风险。技术视角是研发友好的，作为开发人员，天然的可以理解和接受这种技术维度的统一语言：DAO层只负责处理数据相关逻辑，Controller层之服务处理Restful API相关，RPC层只处理与外部系统的跨进程调用等等。首先会想到的例子，比如，如果底层的数据库发生了变更，又或者ORM框架发生了变更，那么，我们只需要修改DAO层的实现，而不需要更改上层的业务层代码。]]></description><category></category></item><item><title><![CDATA[探寻软件架构的本质，到底什么是架构？]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146425654</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146425654</guid><author>SystemEngineeringLab</author><pubDate>Fri, 21 Mar 2025 17:26:51 +0800</pubDate><description><![CDATA[不论是开发人员还是架构师，我们都一直在跟软件系统打交道，架构是在工作中出现最频繁的术语之一。那么，到底什么是架构？你可能有自己的答案，也有可能没有答案。对“架构”的理解需要我们不断在实践中思考、归纳、演绎，形成自己的认知。]]></description><category></category></item><item><title><![CDATA[相比微服务，模块化单体应用架构可能是更好的选择?]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146379113</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146379113</guid><author>SystemEngineeringLab</author><pubDate>Wed, 19 Mar 2025 19:58:49 +0800</pubDate><description><![CDATA[虽然微服务架构风格有其独特优势，但前提是合理架构、划分业务单元。完全无脑的进行微服务化、拆分成庞大的子系统有时并不是一个好的选择，特别是针对初期项目，基于模块化单体应用架构可能是更好的选择。通过系统的不断迭代，随着上下文变化逐渐演进，是一个建议的方式。]]></description><category></category></item><item><title><![CDATA[浅谈业务系统代码与应用架构-回归代码本身]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146379077</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146379077</guid><author>SystemEngineeringLab</author><pubDate>Wed, 19 Mar 2025 19:57:19 +0800</pubDate><description><![CDATA[对于应用系统本身而言，除了满足功能性需求之外，还要满足特定的架构属性（不同的文章对架构属性有不同的称呼，有些称之为“非功能性需求”，有些称为“质量属性”）。]]></description><category></category></item><item><title><![CDATA[状态机模型，你真的搞懂并用对了吗？]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146379039</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146379039</guid><author>SystemEngineeringLab</author><pubDate>Wed, 19 Mar 2025 19:55:41 +0800</pubDate><description><![CDATA[状态机时一种非常有效的抽象的系统行为的分析建模工具，在工程实践中具有较高价值。通过对实体状态建模，有利于业务与技术对领域有一致性理解，并能够有效指导后续的工程实现。值得注意的是，技术人员要对业务状态机和系统状态机有清晰认识，不要混为一谈。由于二者出发视角的不同，技术视角的系统状态机更加偏重于实现，业务状态机更加面向客户。]]></description><category></category></item><item><title><![CDATA[规避系统用例建模的常见 “陷阱” ！]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146378994</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146378994</guid><author>SystemEngineeringLab</author><pubDate>Wed, 19 Mar 2025 19:53:36 +0800</pubDate><description><![CDATA[在业务分析过程中，用例建模是分析需求的重要方式，其本质上是对问题域范围的一种抽象，建模过程也是抽象过程。C4模型中的上下文或边界图也是一种高层的分析建模方式，其表述的目标系统如何融入到当前IT环境，是技术无关的概念。系统用例则表征的是目标系统与参与者的交互，表述目标系统对外提供的功能。见多有四层包含关系的用例图，也见过一张用例图中用例个数超过20个的情况，虽然，“更多的用例可能能够更全面的表达需求”，但，往往会提高干系人的认知成本，严重降低可视化建模带来的有效信息传递效率，使得建模分析的结果大打折扣。]]></description><category></category></item><item><title><![CDATA[聊聊技术方案设计的普遍问题与参考实践]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146341841</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146341841</guid><author>SystemEngineeringLab</author><pubDate>Tue, 18 Mar 2025 15:00:02 +0800</pubDate><description><![CDATA[技术方案的设计没有完全统一的标准，也不应该有强制标准。团队内可以根据自身情况制定可裁剪的技术方案设计模板，作为团队方案设计的参考。“好”的技术方案可能不是面面俱到、事无巨细的表述，应该结合迭代需求/产品建设的上下文灵活的决定技术方案要体现的内容、详细程度等。“好”的技术方案应该是有清晰的背景说明、关键的技术实现方案表述、能够在干系人间达成一致，并能指导团队实施落地。]]></description><category></category></item><item><title><![CDATA[状态机模型，你真的搞懂并用对了吗？]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146336314</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146336314</guid><author>SystemEngineeringLab</author><pubDate>Tue, 18 Mar 2025 11:06:41 +0800</pubDate><description><![CDATA[状态机时一种非常有效的抽象的系统行为的分析建模工具，在工程实践中具有较高价值。通过对实体状态建模，有利于业务与技术对领域有一致性理解，并能够有效指导后续的工程实现。值得注意的是，技术人员要对业务状态机和系统状态机有清晰认识，不要混为一谈。由于二者出发视角的不同，技术视角的系统状态机更加偏重于实现，业务状态机更加面向客户。]]></description><category></category></item><item><title><![CDATA[如何管控与外部系统的对接集成？]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146335994</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146335994</guid><author>SystemEngineeringLab</author><pubDate>Tue, 18 Mar 2025 10:57:57 +0800</pubDate><description><![CDATA[研发部团队在系统建设过程中，多有与公司内外部系统能力对接的场景。对接的质量不尽相同，有些团队对对接的各个环节把控严格，则质量会偏高，有些团队把控较弱，则质量偏低。对接质量直接影响团队的研发成本、开发效率及线上系统稳定。外部集成对接的场景较多，比如对接公司内部成熟能力、对接公司内部团队同步迭代支持的能力、外部供应商能力等等，本文聚焦的场景是公司外部供应商能力对接、公司内部同步迭代支持等需要我方与外部团队紧密协作的场景。]]></description><category></category></item><item><title><![CDATA[简单高效的草图辅助可视化建模]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146335887</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146335887</guid><author>SystemEngineeringLab</author><pubDate>Tue, 18 Mar 2025 10:55:12 +0800</pubDate><description><![CDATA[系统设计过程中基于UML进行可视化建模是普遍的方式，但是，在某些场景下，使用轻量级的草图表述方式比UML图更加简单和高效。其是轻量级的白板工具，支持在线和离线使用方式，可以快速进行草图绘制及团队间的远程沟通协作。建议团队基于自身的建模可视化风格，尽量统一草图的常见图标并形成模板，例如常见的数据库、中间件等，有助于提升图形信息传递效率，降低沟通成本。虽然ExcaliDraw社区的图标库有限（技术领域），但线框图能支持绝大多数草图场景。方式二：打开在线网址，在导航栏右侧点击安装按钮本地安装使用。]]></description><category></category></item><item><title><![CDATA[如何做好团队的技术方案评审？]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146335610</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146335610</guid><author>SystemEngineeringLab</author><pubDate>Tue, 18 Mar 2025 10:49:48 +0800</pubDate><description><![CDATA[团队技术方案评审的效果总是差强人意，低质量的方案评审导致人力成本的浪费以及后期落地成本的增加，本篇文章探讨一下 “如何做好团队技术方案评审？技术方案评审是研发生命周期中最为常见的活动，技术方案评审会是最常见的活动形式。一般由研发人员基于产品需求完成技术方案设计之后，在干系人间发起技术方案的评审。作为架构师几乎每周都会参加1-2次团队的技术方案评审会，每个业务线团队的评审会质量层次不齐。在如此多的干系人参会情况下，如果评审会不能够有效的达成一致性认知，那么其造成的人员成本浪费可想而知。]]></description><category></category></item><item><title><![CDATA[从哲学到工程，聊聊构建高可用分布式系统]]></title><link>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146335487</link><guid>https://blog.youkuaiyun.com/SystemEngineeringLab/article/details/146335487</guid><author>SystemEngineeringLab</author><pubDate>Tue, 18 Mar 2025 10:46:15 +0800</pubDate><description><![CDATA[高可用是系统提供无故障服务的能力。有太多资料探讨如何构建高可用系统，但多是一些工程实践知识点的堆叠。这篇文章我们从更朴素的视角去透视分布式系统的高可用建设]]></description><category></category></item></channel></rss>