QCon Beijing 2009

周爱民

生于无

1、架构不是设计出来的

“设计架构”从根本上就是错误的。

2、架构源于分析，而非设计－设计可以拼搭，架构不可以－设计是既有，架构是源无

“架构(的)设计”讲述了架构的实现和细化过程，但不是“架构”的源起。

系统整合

需求变更

版本升级

插件技术

消息接口

组件技术

计算机科学是研究将现实系统“抽象”为计算机可以理解和运算的系统，并……

问题是，“什么是抽象？”

反过来的问题是，“什么不是抽象？”

既然我们所述的一切，都是“抽象系统”，那么我们——人——是怎么办到的？

抽象思维 形象(具象)思维 灵感思维

问题总是掩盖在需求之后

Felix跑来问我，《现实问题的结构化分析》中讲的为什么都是需求。其实这是错 的。温伯格给问题的定义是“现实与期望之间的差异”，而需求不是这样，需求只 包括“需要的目标”。

你如何描述我们这个会场？

一个大房间？ 上百个人？ 一个投影仪？

房间、人、投影仪……就是抽象。它们并非是具象的，当我用这个名词时，你并不知道它们确指什么、是什么形貌、质量、重量……

我们描述这个会场时，大体还是知道这个“样子”的。

从抽象概念中，我们首先知道共性的东西。但是，由这种共性抽象组织的系统，并不是计算机系统的全部。

例如：原始人开会吗？蚂蚁开会吗？或者，我——一个人——自己可以开会吗？

共性抽象：更加准确地描述系统 本质抽象：更加泛义地描述系统

会场＝开会的地方 开＝交流 会＝集中在一起的群体 地方＝上述行为所依赖的一个位置

所以，一个会议系统，需要： 语音或视频之类的，用于交流的工具，及其管理系统、支持与保障系统；

人员，与会者与听众的管理系统（包括登记、回访等）

位置，例如预约、排程以及会议（地址）通知等。

本质抽象更适合描述架构，而共性抽象更适合于实现、实施系统。

架构本身，是要具备长期的不变性的。它描述的是系统中不变的部分。例如：本质上一个系统是什么？或本质上一个系统应该提供什么？等等。

大系统是必然变化的 变化本身不可预知 战略或目标是确定的、一贯的

当前系统

远期系统

我们关注这个过程中不变的部分

架构的目标是 战略、产品线 具体策略(战术)

大多数情况下，BOSS知道“是什么”，而不知道“如何做”。

大多数情况下，架构师应该知道“如何实现”，以及“实现的目标‘是什么’”。

（同样是）大多数情况下，（一般的）架构师未能了解什么是“战略目标”。

架构通常需要围绕战略目标来提出。

架构师通常最难做到的是了解需求，以及确定变化与不变的部分。

架构是得到一个形式系统，以描绘上述不变部分的一个抽象过程。

在上述这个过程中，“系统”是未得的、不可见的，以及完全“概念化”的。

在上述这个过程中，“系统”是未得的、不可见的，以及完全“概念化”的。“架构”的这个过程，是从无到有的一个过程。

相关物

相关物

相关物

相关物

抽象

原始需求 架构 体系结构

例如外包，就只有实现，没有架构。反过来说，我们要外包给别人，就需要做好架构的工作。要知道整个项目中确定的，不可或缺的，不能失败的是什么。至于哪部分谁做，那是第三步、第四步的问题。

观点：架构是过程而非结果——从无到有的是架构（从未存在过的东西，才是架构）

观点：没有创生(而非创新)，就没有架构。

Prospectus

Requirements

Architecture

High‐LevelDesign

计划和架构设计阶段

发现评审(Discovery Review)

架构评审(Architecture Review)

Low‐LevelDesign

from:Joe MaranzanoATT Bell Labs,USG

“想”，但不是“空想”。凭空想像杜撰出来的是玄幻，不是架构。

看不见

如果你手里有一把锤子，所有东西看上去都像钉子。 心中有锤，就容易为其奴役； 始终莫要忘记提醒自己，“问题是什么？” 没有锤子是万万不行的，没有谁会傻到徒手钉钉

正确的态度应该是：手中有锤，心中无锤。 不要忘掉其适用前提 别忘记自己要解决的问题是什么。Why 永远在 How 之前。

如果你想钉一个钉子，所有东西看上去都像是锤子。 专注于你想要解决的问题，那么你所看到的东西就会呈现出以往你没有看到的一面。

阿基米德洗了一辈子的澡，然而，只有那一次，当他想要解决皇冠密度问题的时候，想到可以利用排水体积来测量不规则物体体积。

1、有时候说实话就是笑话； 2、我们很多笑话是想出来的，是结构出来的。

架构的存在，不要影响业务

大到看不见

小到看不见

设计做大与实施做小

如何做到影响最小？

架构没有好不好，只有合适不合适

关注你的每一项决策

你的建议是否正确？

你在实施团队里吗？

好不好，与能不能

架构的实现是渐次的

如果做不到，那么折衷

折衷，并不是放弃

柔，与弱

勇，与敢，勇敢与勇于不敢

有备无患

若大有

.NET架构概要的历史与影响

架构师要有全局观 现在很多架构只是拥有着一个架构师的头衔，只负责也只了解一个系统局部的、细节的知识。这并不是一个架构师应该的状态，没有全局观的架构师其实只是“负有更大责任的设计师”，因为他们细化、完善乃至于成就这个项目、系统，但是，并不创生它。

从无到有(生于无)观点：架构是过程而非结果——从无到有的是架构           （创生从未存在过的东西，才是架构）观点：架构抽象的两种基本思想方法——由表及里，由此及彼观点：架构不是设计出来的——架构源于分析，而非设计

从有到无(看不见)观点：架构的实现是渐次的——做不出来，则为做出来做准备           （架构实现依赖技术的成熟，而技术成熟是一个过程）观点：架构没有好不好，只有合适不合适观点：架构的存在，不要影响业务——大到看不见，或小到看不见

从无到有(若大有)观点：架构的可变性——无限深远地适应未来

花絮

１、为什么你能吃苹果２、枝节与细节３、尊重反动派