正交性
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

2020-10-11
数据密集型应用系统设计 - Designing Data Intensive Applications
数据密集(Data-Intensive)与计算密集(Compute-Intensive)是当今两大负载类型。前者以大数据为代表,后者以深度学习和 HPC 为主要代表。 谨以本书献给那些追逐梦想的人们。 [另一个电子版本。][1] 前言 数据密集型应用要处理的瓶颈往往是数据的规模、数据的复杂度和数据产生与变化的速率;与之对应的是计算密集型应用,CPU 往往成为其瓶颈。 本书是关于数据处理系统及其相关技术的(NoSQL、消息队列、缓存、搜索引擎、批处理和流处理框架)。 每一种技术都基于一定的设计理念,而且只适用于特定的场景。 不要过度优化。 数据系统基础 可靠、可扩展与可维护的应用系统 现在的典型系统架构已经很明确了,因为业界已经有成功的案例,对这些组件做了很好的抽象,我们只要做好拿来主义就行了。 可靠性(Reliability) fault tolerance 和 resilience 是系统的容错的体现。 硬件故障 对于大型 IDC,即使磁盘的 MTTF 很高,磁盘数量大了以后,每天发生磁盘损坏也是正常的事情。 硬件容错的方案是制造冗余(冗余磁盘、冗余电源)。 软件容错是第二种方...

2022-01-12
《架构师修炼之道》
刻戒于碑,铸法于鼎 软件特性、质量属性。 将两个元素以某种方式连接在一起,就形成了结构。 module component-connector 就是我们经常讲的系统交叉点 allocation 就涉及到我们的部署设计 每一本书都会讲到利益相关者,也就是 stakeholder。 主动撰写设计决策,承担设计职责。 软件之所以叫软件,是因为它灵活而易于变动。架构是软件里硬的部分,为变动提供了章法,也制造了约束-否则我们不用经常“对架构产生冲击”,而需要打破架构。 设计原则: 以人为本(能落地能产生价值的架构才是真的好架构) 推迟决策 善于借鉴 化虚为实 推迟决策不是推迟大的设计决策,要推迟的是细枝末节的决策。不要陷入舍本逐末的优化中,导致项目无法受控。 忽视前人的设计,是最低效的设计方法之一。所以寻找架构风格是很重要的。 设计思维模式: 理解:换位思考 探索:尝试各种结构组合,找到最能提升目标质量属性的那种组合。-大多数情况下,是我们手头最简单最现成的解决方案。 展示:用图、表、模型、原型来展示,探讨。原型应该尽量具有交互性,可以直接和客户评审。 评估:评估到底我们要做什么东西...
2026-10-15
Codex 架构全景:本地运行、云端长任务与多层 Loop
Codex 的架构需要同时回答两个问题:一次编码请求怎样完成,以及请求结束以后,什么状态还能保留、谁会再次启动工作。前一个问题涉及模型、工具和 Harness;后一个问题涉及会话、目标、执行环境、调度和身份。 “Codex 在本地运行”通常表示工作区和工具在本机,模型推理仍可以发生在 OpenAI 的服务器。“Desktop 连 Remote”通常表示客户端通过 SSH 控制远端 App Server;“Cloud 长期运行”则包含托管执行环境及其生命周期。这些模式可以共享执行框架,却承担着不同的运行责任。 本文以 2026 年 10 月 15 日读取的官方产品文档和 Codex rust-v0.162.1 源码为基线,并在 2026 年 10 月 23 日复核 Remote、App Server 与 Code Mode host 的公开边界。源码固定在 092d3acd6bec3e3a14bdc7e7a2810ab628ab759d,提交日期为 2026 年 10 月 9 日;本地 codex --version 为 codex-cli 0.162.1。文中的拓扑是根据公开接口...

2019-12-29
彩色 UML 建模
理论基础与来源 彩色 UML 建模(也称为四色模型)是由 Peter Coad、Eric Lefebvre 和 Jeff De Luca 在经典著作《Java Modeling in Color with UML》中提出的领域建模方法。该方法通过四种颜色区分不同类型的域对象,帮助开发人员更好地理解和设计业务领域模型。 四色模型的核心思想是将领域对象分为四种架构型(Archetype),每种架构型用不同的颜色表示: 粉色(Moment-Interval):表示业务过程中发生的某个时刻或时段 黄色(Role):表示参与方在特定时刻时段中扮演的角色 绿色(Party-Place-Thing):表示参与方、地点和事物 蓝色(Description):表示描述性信息,通常是可重用的数据 四色模型与 DDD 的关系 四色模型与领域驱动设计(Domain-Driven Design,DDD)有很强的关联性: 关注领域本质:两者都强调深入理解业务领域,建立符合业务语义的模型 限界上下文:四色模型的彩色分类可以帮助识别和定义限界上下文 聚合根:粉色 MI 通常对应聚合根,负责维护业务不变性 ...

2021-05-07
如何画架构图
前言 有意义且具备一致性(coherence)的架构图有助于为不同的利益相关者(stakeholder)澄清(illustrate)事实,并达成共识-反之,图表杂乱无章。 有意义的图表胜过建模(建模指的是With modelling, you're building up a non-visual model of something (e.g. the software architecture of a software system), and then creating different views (e.g. diagrams) on top of that model. ),在架构沟通上,visualization 胜过千言万语。 一致性要求我们有足够好的指导原则,让我们知道标准的图元是什么。 “架构是一项复杂的工作,只使用单个图表来表示架构很容易造成莫名其妙的语义混乱”。 在同一个架构图里添加不同层级的抽象可能会导致冲突的出现,因为它们是从不同的角度描述问题的。 应该在架构图旁边加上图例(legend),沟通者应该懂得图元(key)是什么。key 和 legen...

2022-01-19
演进式架构
如果读一本书,没有附带正确的复盘(提出反馈并总结反馈),则浪费了这次读书的完整机会。 复盘需要经过痛苦的思索,把一些之前自己没有办法充分接受的观点,充分接受。 本书是一本讲战略的书。 这本书告诉我们很多概念,一旦加上“架构”前缀,突然就有了特殊的含义:架构特征(architectural characteristic)、架构量子(architectural quantum)、架构维度(architectural dimension)、架构模式(architectural pattern)。 新时代的架构愿景-怎样用敏捷的方式来拥抱变化? 架构难以被修改是由架构本身的不变性决定的,架构天然就是难以修改的。 有些人可能认为,就好像建筑业的实践那样,应该先完成这类架构设计,再开始开发。但需求是快速变动的这一事实告诉我们,我们可能要经常修改我们架构,以拥抱需求变化。 “需求总是在动态变化的”,比“架构应该是被预先确定”,更加像是一个事实(后者更加像是一个观点)。 当代的架构是: 不断努力的结果 【能够响应不断变化的需求和外部人员的反馈】 实施这种架构以替代传统架构,是需要决策者(技术...
Announcement
人生只是,守株待兔





