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

2021-02-10
《恰如其分的软件架构》
前言 这两周集中时间间歇性读完了《恰如其分的软件架构》这本书。这本书讲的是架构方法,架构方法是一种思维模型(mind set),这种思维模型叫作“风险驱动模型”。 这本书经我们团队的架构师推荐,列在我们团队的集体书目里很久了。但真正去读它、读完它的人又很少。究其原因,还是这本书的内容以谈概念为主,虽然书中举的例子非常生动,仍然始终无法摆脱“为了谈概念而举玩具例子”的问题-这几乎是所有架构书的通病。似乎正统的架构书籍都不可避免地举一些传统行业或者经典软件(比如很多书籍都会反复出现在“xxx 播放器”)的例子。这些软件架构非常经典,可以只用一些小的组件、场景,就讲清楚典型的组件、模式和架构风格的用处。但没有很深的工程/架构经验的读者读这些书的时候,仿佛重新回到了抄书和念书的大学课堂,对于脱离现实的例子只会产生“左耳进右耳出”的感觉。能够温故而知新,是一本书经典化的特征。而能够阅读非入门级的纯理论书籍,则是一个程序员的认知能力和经验达到了一定程度的特征。我读这本书里很多细节还是很痛苦,证明我还是对于形式化的符号(symbol)、记法(notion)还不是很熟悉,而且对于书中运用的问题解...

2020-12-08
活动保障性体系建设和实践的总结
大促规划.xmind 活动的定义和特点 活动具有大并发、高流量的特点,前期充足的准备是活动顺利完成的必要条件。 准备好完备的保证流程,可以为相关人员提供指引。 基本的保障方案 事前:严格按照保障步骤分工执行,活动要报备,核心链路要梳理,梳理完要评估容量和准备,要治理风险,要准备预案,要建设大盘,准备压测和演练预案,要安排值班。 事中:相关责任方(要分技术负责人和运维负责人,召集相关人员,组成稳定性保障小组)监控线上数据,以线上/线下会议、群聊和电话等多个方式参与值班并及时响应异常事件。 事后:组织复盘,总结亮点,指出不足,沉淀经验。 活动报备 要理清活动信息:活动背景、活动时间、用户参与路径、活动链接、活动 玩法、预计UV数、负责人。 核心链路的设计与梳理 核心链路的梳理、设计需和活动保障的几个核心要素相结合,核心要素分为:隔离、限流、容量。 隔离:域名隔离、Nginx集群隔离、核心服务隔离、以及其他一些重要服务的隔离。 限流:前端活动业务限流、Nginx限流(HTTP限流)、服务限流(RPC)等。特别要关注接入层的限流能力和方案。 容量:从域名解析到后端存储的系列容量评...

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 通常对应聚合根,负责维护业务不变性 ...
2019-09-05
《应用架构之道》笔记
架构师的职责 化繁为简。架构师是职责就是把复杂的问题简单化,使得其他人能够更好地在架构里工作。 架构师要努力训练自己的思维,用它去理解复杂的系统,通过合理的分解和抽象,做出合理的设计。 软件架构 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件的链接则明确和相对细致地描述组件之间的通信。 软件架构为软件系统提供了结构、行为和属性的高级抽象。,由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系,而且指定了整个软件系统的组织和拓扑结构,提供了一些设计决策的基本原理。 软件架构的核心价值应该只围绕一个核心命题:控制复杂性。 软件架构分类 业务架构:由业务架构师负责,也可以称为业务领域专家、行业专家。业务架构属于顶层设计,其对业务的定义和划分会影响组织结构和技术架构。 应用架构:由应用架构师负责,他需要根据业务场景的需要,设计应用的层次结构,制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平,从而在快速的支撑业务发展的同时,在保证系统的可用性和可维...
2021-08-25
基本业务架构设计方法
如何实现自己的 validation 123456789101112131415161718192021222324252627282930313233343536373839// 抛出异常private void validateParam(Map<String, String> paramValues) { boolean validate = MapUtils.isEmpty(paramValues) || !paramValues.containsKey(ParamConstant.CUSTOMER_N0) || StringUtils.isEmpty(paramValues.get(ParamConstant.CUSTOMER_N0)); if (validate) { throw new DataBusinessException(ResultCodeEnum.PARAM_NULL); } ...

2022-01-10
郭东白博士《关于中台的思考和尝试》
FROM:《关于中台的思考和尝试》 围绕中台的争议非常多,但是往往争议的原因是连中台这个概念都完全没有达成共识,可以说是毫无意义的争吵。在 12 月 20 日由极客邦科技举办的 QCon 全球软件开发大会 2020(上海站)上,车好多 CTO 郭东白博士发表了主题演讲《从中台技术谈架构师的独立思考能力》。由于演讲时间有限, 关于中台的思考没办法讲得非常透彻,本文是对演讲的补充,期望能与大家形成思想碰撞。识别文末二维码,可免费下载郭东白博士的主题演讲PPT。 中台的定义 我们的讨论先从定义中台这个概念开始。 定义中台我认为可以有两个角度, 一个是从中台本身的价值和出发点来: 中台是在多个部门之间共享的开发资源所提供的业务能力、数据能力和计算能力的集合;另一个定义从中台的相对定位来:前台是面向终端用户的一组业务能力,业务中台是对前台应用的抽象,提供多个前台业务之间共享的业务逻辑、数据和计算能力。 我想特别强调这个定义是相对中性的, 我们能够通过这个定义区分什么东西是中台,什么不是中台。有的中台定义严格来说不是定义, 比如说“中台是提升效率和加速业务增长的一种工具”、“中台是我们的战略...
Announcement
人生只是,守株待兔





