JUST ENOUGH SOFTWARE ARCHITECTURE

JerryXia 发表于 2018-08-22 09:47:47 , 阅读 (0)

本书算是个总结整理, 没看出提出了什么新的观点和方法

本书倒是明确了几个词汇, 丰富了设计时可用与思考和交流的语言

工程风险与项目管理风险

后者可以认为是乙方的business risk

明确提出这两个词汇后，可以思考和理解常见的几个问题：工程师和产品经理/项目经理经常在优先级上有不同意见，原因是前者没有充分理解business risk，后者没有充分理解工程风险，因此使用统一语言就变得必要.

鉴于工程师的弱势地位, 应该是工程师用业务语言来描述工程风险 , 来争取自己的主张.

设计技术与设计活动

这两者通常被混为一谈，而其实前者回答的是针对何种问题选择何种技术和模型来解决，后者回答的是何时开始设计，何时停止，本书第一部分说的是后者，第二部分说的是前者

软件开发过程与设计活动采用的方法

二者是正交的，风险驱动的设计方法可以用于瀑布，迭代，螺旋等，因为无论是瀑布，迭代还是螺旋. 都要回答何时开始设计何时停止

局部重构与架构重构

明确指出目前流行的重构技术偏向于局部重构. 架构重构明显缺乏指导

过程性知识与陈述性知识

能击中网球与知道如何为何能击中网球明显不同. Talk不是那么cheap, Code也不是那么贵

求解与证明

软件架构是求解，而不是证明

领域模型，设计模型与代码模型

外延式与内涵式

这俩词太抽象了, 简单说就是代码是有局限的，代码无法直接表达内涵式，比如职责分配, 设计决策, 基本原理, 协议，质量属性等

但也有方法：Intention Revealing Naming, Annotation等

列举了些影响架构决策的因素, 如复杂度，规模，地理位置，关键性，领域，客户等

回答了设计何时停止的问题: 能够消除风险, 回答预设的问题的时候

建议了描述设计决策的方式: x约束更重要，因此我们采用y方案，并愿意承担后果z

部署视图或许是最有用一种视图

当存在难以解释的困惑时，通常需要新的角度和语言

真正的困难在于知道和做到之间的距离

既然存在领域设计，就应该存在领域测试. 成都办公室的Liu Ran在致力于领域测试

[ 技术文章推荐 ]