Loading...
守株阁Gergely Orosz 文章翻译-软件架构被高估,简明设计被低估 Back to Home

Gergely Orosz 文章翻译-软件架构被高估,简明设计被低估

Created2022-01-19|Updated2026-01-24
|Word Count:14|Reading Time:1mins|Post Views:

原文链接:《Software Architecture is Overrated, Clear and Simple Design is Underrated》

Author: magicliang
Link: https://magicliang.github.io/2022/01/19/Gergely-Orosz-%E6%96%87%E7%AB%A0%E7%BF%BB%E8%AF%91-%E8%BD%AF%E4%BB%B6%E6%9E%B6%E6%9E%84%E8%A2%AB%E9%AB%98%E4%BC%B0%EF%BC%8C%E7%AE%80%E6%98%8E%E8%AE%BE%E8%AE%A1%E8%A2%AB%E4%BD%8E%E4%BC%B0/
Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
系统架构翻译
Related Articles
cover
2021-02-10
《恰如其分的软件架构》
前言 这两周集中时间间歇性读完了《恰如其分的软件架构》这本书。这本书讲的是架构方法,架构方法是一种思维模型(mind set),这种思维模型叫作“风险驱动模型”。 这本书经我们团队的架构师推荐,列在我们团队的集体书目里很久了。但真正去读它、读完它的人又很少。究其原因,还是这本书的内容以谈概念为主,虽然书中举的例子非常生动,仍然始终无法摆脱“为了谈概念而举玩具例子”的问题-这几乎是所有架构书的通病。似乎正统的架构书籍都不可避免地举一些传统行业或者经典软件(比如很多书籍都会反复出现在“xxx 播放器”)的例子。这些软件架构非常经典,可以只用一些小的组件、场景,就讲清楚典型的组件、模式和架构风格的用处。但没有很深的工程/架构经验的读者读这些书的时候,仿佛重新回到了抄书和念书的大学课堂,对于脱离现实的例子只会产生“左耳进右耳出”的感觉。能够温故而知新,是一本书经典化的特征。而能够阅读非入门级的纯理论书籍,则是一个程序员的认知能力和经验达到了一定程度的特征。我读这本书里很多细节还是很痛苦,证明我还是对于形式化的符号(symbol)、记法(notion)还不是很熟悉,而且对于书中运用的问题解...
cover
2022-03-11
面向好的架构编程
前言 本文是《架构随笔》系列的第五篇,也是它的收官之作。 架构的定义 架构是一个界定不清的东西,我们很难讲清楚哪些东西是架构,哪些东西不是架构。但软件行业里其实人人都在搞架构,软件设计就是架构本身。 架构这个词出现得很早,有些人认为是 NASA(也可能是NATO) 发明的。最早的架构定义就是描述软件的结构而已,但现在已经没有多少人谈论他们定义的“软件架构”了。工程师很难以克制描述复杂结构的原始冲动,但描述复杂结构的普世标准并不存在。大家常见的各种定义,翻来覆去地重新讲着“软件架构是软件结构的顶层设计或者抽象设计”之类的话。即使是这种软件架构的定义,也并不为所有人都接受。汗牛充栋的架构书籍里有各种各样的观点,有的进一步把软件架构视作一堆组件和交互的设计,有的则把软件架构视作架构师主观意图的体现。把自己当作架构师的人们,着迷于把软件里的“不变与抽象的部分”和“易变与具体的部分”分离出来,把前者当作架构。架构师们是如此地热衷于做这样一件事,以至于有些人认为架构设计好了就解决了基本问题,设计不好通常是因为架构不好。于是很多人开始刻舟求剑:从某某颗粒度开始的设计应该叫概要设计,从某某颗粒度...
cover
2018-04-02
一个滚动重启的状态保存问题
很多时候滚动重启,都会导致状态丢失。比较好的设计方法是把服务本身设计成无状态的,然后在上游的服务上做好 failover,然后增加 standby server,让 sticky 数据 transmit 到 standby 机器上,让 request 失败以后可以自己由上游重传到 standby server。然后就可以滚动重启了。 这大部分场景下还要考虑幂等的问题。 这就看得出热配置热替换的重要性了。在大多数情况下,除了发布新的 feature 升级以外,都应该尽量用热配置来避免重启。
cover
2020-06-01
交易系统模型设计
交易系统.xmind
cover
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 通常对应聚合根,负责维护业务不变性 ...
cover
2022-01-20
常见架构推导法
架构演进之路,路漫漫其修远兮 架构关乎不变的顶层设计抽象。 架构关乎组件(元素)、交互(连接器)、功能(function or feature)、约束(constraint 面向当前、未来-下一场景、下一个规模、下一个地域或国家) 洋葱架构的另一种解读 系统是洋葱,看似有边界,但是每次改动总是端到端,过程让⼈人泪流满⾯面。 系统的本质 功能与质量量的结合体:功能是核心价值 + 质量实现增值或保值。 系统的复杂性 过程与过程数据 过程与过程数据.drawio 易变性 系统复杂度.drawio 系统复杂度 = 功能的数量 * 功能的过程 《人月神话》:本质复杂度(Essential Complexity)和偶然复杂度(Accident Complexity)。 解法 分离业务复杂度和系统复杂度。 回归面向对象的本质,重拾抽象思维的价值 维护效率曲线.drawio 三种编程范型.drawio 领域驱动设计 战略设计 领域驱动设计-战略设计-一般过程.drawio 需求分析 需求分析.xmind 词汇提取 知识提取.drawio 领域语⾔定义-合理的上下⽂和领域划分 顺序-...
avatar
magicliang
关于技术以及人生
Articles
359
Tags
271
Categories
13
Github
Announcement
人生只是,守株待兔
Recent Posts
驾驭工程:从 Prompt Engineering 到 Harness Engineering 的范式跃迁
驾驭工程:从 Prompt Engineering 到 Harness Engineering 的范式跃迁2026-03-21
子 Agent 的本质:上下文隔离与专门化
子 Agent 的本质:上下文隔离与专门化2026-03-19
Coding Agent 架构祛魅:从 Claude Code 到 OpenCode 的真实实现
Coding Agent 架构祛魅:从 Claude Code 到 OpenCode 的真实实现2026-03-19
git worktree 术语起源解析
git worktree 术语起源解析2026-03-18
告别 Vibe Coding:用 OmO 构建可靠的 AI 工程系统
告别 Vibe Coding:用 OmO 构建可靠的 AI 工程系统2026-03-18
© 2017 - 2026 By magicliangFramework Hexo 8.1.1|Theme Butterfly 5.5.4