Gergely Orosz 文章翻译-软件架构被高估，简明设计被低估
原文链接：《Software Architecture is Overrated, Clear and Simple Design is Underrated》
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2018-11-28
正交性
所谓正交性（orthogonal 意为正交的），就是设计的维度与其他维度完全隔离，一个正交的设计/值域设计，其变化绝不会受其他正交维度影响，也不会影响其他正交维度。 我们可以把 API 设计成正交的。这样 API 有独立变化的空间的。 我们可以把问题域切分清楚。问题域之间完全不相互干涉（注意跨问题域问题）。 我们可以把变量、字段、列设计成正交的。这样不同业务场景下，列之间的赋值不会相互覆盖。
2022-03-11
面向好的架构编程
前言 本文是《架构随笔》系列的第五篇，也是它的收官之作。 架构的定义 架构是一个界定不清的东西，我们很难讲清楚哪些东西是架构，哪些东西不是架构。但软件行业里其实人人都在搞架构，软件设计就是架构本身。 架构这个词出现得很早，有些人认为是 NASA（也可能是NATO） 发明的。最早的架构定义就是描述软件的结构而已，但现在已经没有多少人谈论他们定义的“软件架构”了。工程师很难以克制描述复杂结构的原始冲动，但描述复杂结构的普世标准并不存在。大家常见的各种定义，翻来覆去地重新讲着“软件架构是软件结构的顶层设计或者抽象设计”之类的话。即使是这种软件架构的定义，也并不为所有人都接受。汗牛充栋的架构书籍里有各种各样的观点，有的进一步把软件架构视作一堆组件和交互的设计，有的则把软件架构视作架构师主观意图的体现。把自己当作架构师的人们，着迷于把软件里的“不变与抽象的部分”和“易变与具体的部分”分离出来，把前者当作架构。架构师们是如此地热衷于做这样一件事，以至于有些人认为架构设计好了就解决了基本问题，设计不好通常是因为架构不好。于是很多人开始刻舟求剑：从某某颗粒度开始的设计应该叫概要设计，从某某颗粒度...
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 通常对应聚合根，负责维护业务不变性 ...
2022-01-10
面向不确定性编程
本文是如何写《复杂业务系统》和《我眼中的阿里经济体的中台架构演进》的续篇。 本文探讨到底不确定性和复杂性源于何处，并引出互联网业务系统的一种“可适应性架构”，适用于平台型业务系统。 定义问题 软件难写，是软件工程师的共同感觉。 特别地，对于中国的互联网公司的“业务团队”的工程师而言，“业务系统”在业务的复杂度堆积到一定程度以后，软件本身的“熵增效应”会特别严重：一个业务系统的内部会充满了难以理解的分层、堆积如山的 if-else 分支，以至于很多工程师都不愿意进入密密麻麻复杂逻辑深处，去做高风险的维护工作。但是，只要公司正常发展，业务总会越做越大/复杂，所以要维持系统的可维护性，成为了一门很重要的学问。 现实中的系统的高复杂度问题，可以简单表述为“不确定性矛盾”：需求具有高度不确定性，一直都在高速变化；而工程师高度倾向于确定实现（因为高度抽象、反复抽象的成本很高），所以具体的实现难以变更，这两种相反的特性难以调和。 其实我们现在遇到的困境，历史上发生过很多次，比如我们现代的很多软件工程理论，就是从历次的软件危机中诞生的。归根结底，软件之所以叫软件（Software），是因为相...
2022-01-10
郭东白博士《关于中台的思考和尝试》
FROM：《关于中台的思考和尝试》 围绕中台的争议非常多，但是往往争议的原因是连中台这个概念都完全没有达成共识，可以说是毫无意义的争吵。在 12 月 20 日由极客邦科技举办的 QCon 全球软件开发大会 2020（上海站）上，车好多 CTO 郭东白博士发表了主题演讲《从中台技术谈架构师的独立思考能力》。由于演讲时间有限， 关于中台的思考没办法讲得非常透彻，本文是对演讲的补充，期望能与大家形成思想碰撞。识别文末二维码，可免费下载郭东白博士的主题演讲PPT。 中台的定义 我们的讨论先从定义中台这个概念开始。 定义中台我认为可以有两个角度， 一个是从中台本身的价值和出发点来： 中台是在多个部门之间共享的开发资源所提供的业务能力、数据能力和计算能力的集合；另一个定义从中台的相对定位来：前台是面向终端用户的一组业务能力，业务中台是对前台应用的抽象，提供多个前台业务之间共享的业务逻辑、数据和计算能力。 我想特别强调这个定义是相对中性的， 我们能够通过这个定义区分什么东西是中台，什么不是中台。有的中台定义严格来说不是定义， 比如说“中台是提升效率和加速业务增长的一种工具”、“中台是我们的战略...
