正交性
Created|Updated|系统架构
|Word Count:157|Reading Time:1mins|Post Views:
所谓正交性(orthogonal 意为正交的),就是设计的维度与其他维度完全隔离,一个正交的设计/值域设计,其变化绝不会受其他正交维度影响,也不会影响其他正交维度。
我们可以把 API 设计成正交的。这样 API 有独立变化的空间的。
我们可以把问题域切分清楚。问题域之间完全不相互干涉(注意跨问题域问题)。
我们可以把变量、字段、列设计成正交的。这样不同业务场景下,列之间的赋值不会相互覆盖。
Author: magicliang
Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2022-01-10
面向不确定性编程
本文是如何写《复杂业务系统》和《我眼中的阿里经济体的中台架构演进》的续篇。 本文探讨到底不确定性和复杂性源于何处,并引出互联网业务系统的一种“可适应性架构”,适用于平台型业务系统。 定义问题 软件难写,是软件工程师的共同感觉。 特别地,对于中国的互联网公司的“业务团队”的工程师而言,“业务系统”在业务的复杂度堆积到一定程度以后,软件本身的“熵增效应”会特别严重:一个业务系统的内部会充满了难以理解的分层、堆积如山的 if-else 分支,以至于很多工程师都不愿意进入密密麻麻复杂逻辑深处,去做高风险的维护工作。但是,只要公司正常发展,业务总会越做越大/复杂,所以要维持系统的可维护性,成为了一门很重要的学问。 现实中的系统的高复杂度问题,可以简单表述为“不确定性矛盾”:需求具有高度不确定性,一直都在高速变化;而工程师高度倾向于确定实现(因为高度抽象、反复抽象的成本很高),所以具体的实现难以变更,这两种相反的特性难以调和。 其实我们现在遇到的困境,历史上发生过很多次,比如我们现代的很多软件工程理论,就是从历次的软件危机中诞生的。归根结底,软件之所以叫软件(Software),是因为相...
2019-09-05
《应用架构之道》笔记
架构师的职责 化繁为简。架构师是职责就是把复杂的问题简单化,使得其他人能够更好地在架构里工作。 架构师要努力训练自己的思维,用它去理解复杂的系统,通过合理的分解和抽象,做出合理的设计。 软件架构 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件的链接则明确和相对细致地描述组件之间的通信。 软件架构为软件系统提供了结构、行为和属性的高级抽象。,由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系,而且指定了整个软件系统的组织和拓扑结构,提供了一些设计决策的基本原理。 软件架构的核心价值应该只围绕一个核心命题:控制复杂性。 软件架构分类 业务架构:由业务架构师负责,也可以称为业务领域专家、行业专家。业务架构属于顶层设计,其对业务的定义和划分会影响组织结构和技术架构。 应用架构:由应用架构师负责,他需要根据业务场景的需要,设计应用的层次结构,制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平,从而在快速的支撑业务发展的同时,在保证系统的可用性和可维...

2023-02-13
推荐系统相关
新闻的推荐系统是为了给信息流的用户推荐资讯 feed。接口返回的信息不一定会被外显曝光。 在瀑布流式的外显曝光场景下,重排能够减少用户的疲劳度。 这就涉及到推荐系统的设计,流量要经过什么样的链路呢? 接入层、推荐中控、画像、召回、粗排、精排、重排。这些系统会形成星型架构和树形架构。 不同的架构之间有一个典型的优缺点需要取舍:链路长度会影响网络传输的最终效率,也会影响推荐系统的性能。 feeds推荐引擎典型架构.drawio

2022-01-12
《架构师修炼之道》
刻戒于碑,铸法于鼎 软件特性、质量属性。 将两个元素以某种方式连接在一起,就形成了结构。 module component-connector 就是我们经常讲的系统交叉点 allocation 就涉及到我们的部署设计 每一本书都会讲到利益相关者,也就是 stakeholder。 主动撰写设计决策,承担设计职责。 软件之所以叫软件,是因为它灵活而易于变动。架构是软件里硬的部分,为变动提供了章法,也制造了约束-否则我们不用经常“对架构产生冲击”,而需要打破架构。 设计原则: 以人为本(能落地能产生价值的架构才是真的好架构) 推迟决策 善于借鉴 化虚为实 推迟决策不是推迟大的设计决策,要推迟的是细枝末节的决策。不要陷入舍本逐末的优化中,导致项目无法受控。 忽视前人的设计,是最低效的设计方法之一。所以寻找架构风格是很重要的。 设计思维模式: 理解:换位思考 探索:尝试各种结构组合,找到最能提升目标质量属性的那种组合。-大多数情况下,是我们手头最简单最现成的解决方案。 展示:用图、表、模型、原型来展示,探讨。原型应该尽量具有交互性,可以直接和客户评审。 评估:评估到底我们要做什么东西...
2026-02-07
API 兼容性设计
在软件工程中,API 兼容性是一个至关重要但又经常被忽视的问题。良好的兼容性设计能够确保系统的平滑演进,避免因 API 变更导致的客户端崩溃和服务中断。本文将从多个维度探讨 API 兼容性设计的最佳实践。 什么是 API 兼容性 API 兼容性分为两种类型: 向前兼容:旧版本的客户端能够与新版本的服务端正常通信。即服务端升级后,旧客户端仍能正常工作。 向后兼容:新版本的客户端能够与旧版本的服务端正常通信。即客户端升级后,旧服务端仍能提供服务。 在实际项目中,我们通常更关注向前兼容,因为服务端的升级往往不可控,而客户端的更新节奏各异。 破坏性变更的分类 破坏性变更是指会导致现有客户端无法正常工作的 API 变更。主要分为三类: 1. 接口签名变更 123456789// 变更前public interface UserService { User getUser(String userId);}// 变更后 - 破坏性变更public interface UserService { User getUser(String userId,...
2021-08-18
如何写系统规划
列出背景 列出现状。 列出当前组织的 okr,分析机会和挑战。 将当前系统的视图勾勒出来,要能理解信息流和资金流。 列出痛点,分析需要实现的技术能力。 对标 对标其他团队的成功经验。 分析背景和成功原理。 要有架构图。 解决方案 要有目标架构图 有问题拆解:什么服务,是什么问题域的解空间,拥有什么能力,建设路径分几期,需要多少人力成本。 全团队分工: 本团队产品怎么分工 本团队后端怎么分工 本团队前端怎么分工 本团队数据怎么分工 本团队算法怎么分工 其他团队怎么分工 里程碑 按照绝对时间拆解 按照任务事件拆解 如何画简单的架构图 水平分层极其重要,每一层左边在层次里会有层次说明。 要用圆角都用圆角,要用直角都用直角。 重点:要填满整个空间: 深底色配白字。 模块之间的应该要直,不然应该优美、松弛。 图像应该紧凑,不留缝隙。 越处于背景之中,颜色越浅。 有时候,利用立体图形是好的。 要有阴影。 要玻璃化。
Announcement
人生只是,守株待兔





