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-01-10
郭东白博士《关于中台的思考和尝试》
FROM：《关于中台的思考和尝试》 围绕中台的争议非常多，但是往往争议的原因是连中台这个概念都完全没有达成共识，可以说是毫无意义的争吵。在 12 月 20 日由极客邦科技举办的 QCon 全球软件开发大会 2020（上海站）上，车好多 CTO 郭东白博士发表了主题演讲《从中台技术谈架构师的独立思考能力》。由于演讲时间有限， 关于中台的思考没办法讲得非常透彻，本文是对演讲的补充，期望能与大家形成思想碰撞。识别文末二维码，可免费下载郭东白博士的主题演讲PPT。 中台的定义 我们的讨论先从定义中台这个概念开始。 定义中台我认为可以有两个角度， 一个是从中台本身的价值和出发点来： 中台是在多个部门之间共享的开发资源所提供的业务能力、数据能力和计算能力的集合；另一个定义从中台的相对定位来：前台是面向终端用户的一组业务能力，业务中台是对前台应用的抽象，提供多个前台业务之间共享的业务逻辑、数据和计算能力。 我想特别强调这个定义是相对中性的， 我们能够通过这个定义区分什么东西是中台，什么不是中台。有的中台定义严格来说不是定义， 比如说“中台是提升效率和加速业务增长的一种工具”、“中台是我们的战略...
2022-01-19
演进式架构
如果读一本书，没有附带正确的复盘（提出反馈并总结反馈），则浪费了这次读书的完整机会。 复盘需要经过痛苦的思索，把一些之前自己没有办法充分接受的观点，充分接受。 本书是一本讲战略的书。 这本书告诉我们很多概念，一旦加上“架构”前缀，突然就有了特殊的含义：架构特征（architectural characteristic）、架构量子（architectural quantum）、架构维度（architectural dimension）、架构模式（architectural pattern）。 新时代的架构愿景-怎样用敏捷的方式来拥抱变化？ 架构难以被修改是由架构本身的不变性决定的，架构天然就是难以修改的。 有些人可能认为，就好像建筑业的实践那样，应该先完成这类架构设计，再开始开发。但需求是快速变动的这一事实告诉我们，我们可能要经常修改我们架构，以拥抱需求变化。 “需求总是在动态变化的”，比“架构应该是被预先确定”，更加像是一个事实（后者更加像是一个观点）。 当代的架构是： 不断努力的结果 【能够响应不断变化的需求和外部人员的反馈】 实施这种架构以替代传统架构，是需要决策者（技术...
2022-01-12
《架构师修炼之道》
刻戒于碑，铸法于鼎 软件特性、质量属性。 将两个元素以某种方式连接在一起，就形成了结构。 module component-connector 就是我们经常讲的系统交叉点 allocation 就涉及到我们的部署设计 每一本书都会讲到利益相关者，也就是 stakeholder。 主动撰写设计决策，承担设计职责。 软件之所以叫软件，是因为它灵活而易于变动。架构是软件里硬的部分，为变动提供了章法，也制造了约束-否则我们不用经常“对架构产生冲击”，而需要打破架构。 设计原则： 以人为本（能落地能产生价值的架构才是真的好架构） 推迟决策 善于借鉴 化虚为实 推迟决策不是推迟大的设计决策，要推迟的是细枝末节的决策。不要陷入舍本逐末的优化中，导致项目无法受控。 忽视前人的设计，是最低效的设计方法之一。所以寻找架构风格是很重要的。 设计思维模式： 理解：换位思考 探索：尝试各种结构组合，找到最能提升目标质量属性的那种组合。-大多数情况下，是我们手头最简单最现成的解决方案。 展示：用图、表、模型、原型来展示，探讨。原型应该尽量具有交互性，可以直接和客户评审。 评估：评估到底我们要做什么东西...
2021-08-18
如何写系统规划
列出背景 列出现状。 列出当前组织的 okr，分析机会和挑战。 将当前系统的视图勾勒出来，要能理解信息流和资金流。 列出痛点，分析需要实现的技术能力。 对标 对标其他团队的成功经验。 分析背景和成功原理。 要有架构图。 解决方案 要有目标架构图 有问题拆解：什么服务，是什么问题域的解空间，拥有什么能力，建设路径分几期，需要多少人力成本。 全团队分工： 本团队产品怎么分工 本团队后端怎么分工 本团队前端怎么分工 本团队数据怎么分工 本团队算法怎么分工 其他团队怎么分工 里程碑 按照绝对时间拆解 按照任务事件拆解 如何画简单的架构图 水平分层极其重要，每一层左边在层次里会有层次说明。 要用圆角都用圆角，要用直角都用直角。 重点：要填满整个空间： 深底色配白字。 模块之间的应该要直，不然应该优美、松弛。 图像应该紧凑，不留缝隙。 越处于背景之中，颜色越浅。 有时候，利用立体图形是好的。 要有阴影。 要玻璃化。
2022-03-18
如何写业务代码
业务研发面对的问题 稳定的业务模式 不稳定的需求 业务对交付的渴望 假设 命名规范（《clean code》） 面向对象设计（SOLID原则、贫血/充血模型、设计模式） 系统要拆分 流程控制系统与领域系统.drawio 每一个用例（解决的一个问题）都由访问逻辑和执行逻辑组成。访问逻辑负责用例执行的顺序与分支，并调用执行逻辑完成完整业务逻辑。 访问逻辑由单独的交易系统负责。执行逻辑由个子系统负责。 工程要拆分 三层架构 + 洋葱架构 代码要拆分 业务代码：描述核心业务逻辑的代码，核心是保持业务的流程及业务状态的一致性 领域对象与领域服务，不得对外部有任何依赖（工具类除外） 最核心的几个抽象： 校验：参数有效性校验、参数的业务属性校验。在进入正常业务逻辑代码前，完成所有的校验工作。 异常：业务异常：所有不符合业务逻辑而产生的异常。 系统异常：因为程序本身or依赖产生的异常。 所有的异常第一位runningtime异常。 数据: 业务数据：保存领域对象状态的数据。 非业务数据：过程数据。业务的核心流程中，只对业务数据的持久化负责。 参数：任何时候，任何方法的参数都需要...
