大数据&云平台潮流下
新一代架构设计思维、方法和技术
-- 应用于数字家庭、物联网和智慧城市顶层设计
课程简介：
◆ 各平台皆适用的架构设计方法
这是一个人人都能学习的新潮课程；也是在当今智能(和移动互联网)时代里，各平台的设计者、开发者都需要的新思想、方法和模式。
◆ 面对复杂，唯有简单
在当今智能(和移动互联网)时代里，各式各样的设备都透过网络相联而整合起来。就产生了许多种复杂的整合形式，例如云&端整合、软硬件整合、多机整合等。凡是涉及”整合”，都必须仰赖有效的减法设计。因为整合本身就是加法思维，唯有先进行减法、设计出简单架构，才能有效、迅速地进行加法(即整合)，并避免加法而产生复杂。
◆ 架构+敏捷：设计出简单，掌握了复杂
高老师教你一项<架构与敏捷完美组合>的途径(方法)，让你花两天时间，就能学会如何设计出简单来掌握复杂的技能了。此方法的要点如下：
★ 面对互(物)联网的复杂，我们需要减法设计
★ 有效的减法设计：以软件接口包容通信协议
★ 接口、组合与创新：新一代架构设计的核心
★ 接口落实为EIT代码：是敏捷开发的好起点
★ 需求是限制：需求检验架构，创意爱上限制
★ 熟谙设计思考，务实减法，以简单掌握复杂
此方法的详尽介绍，可看看高老师的：”认识<新一代创新型架构设计方法>”。
◆ 满意：让用户获得从简单中叫出复杂的满足感
架构&设计围绕着问题(Problem)；设计&创意拥抱着需求(Requirements)。创意&敏捷激发团队的创新(Creativity)氛围。敏捷迭代与代码测试(Testing)让创意深深爱上(需求)限制，认用户获得了从简单(来自设计&创新)里叫复杂(来自智能&联网)的满足感。
◆ 外行人看热闹，内行人看门道
俗语说，内行人看门道；专业的视角、专业的造形(Form)和模式(Pattern)就是其中之道。因此，本课程将带领学员以内行人的视角，领会设计思考、设计出未来性、落实为代码、且需求检验架构。于是，确保了架构设计的最佳性、可实现性和团队的敏捷性。
课程大綱：
内容
Part-1. 目标：从<稳定抽象>到<实践创新>
Part-2. 眼光：以新视角看日益复杂的架构
Part-3. 抽象与组合：必备的思维、方法和模式
Part-4. 范例：设计方法的应用实例解析
Part-5. 多层架构：如何在C/C++平台上建立Java框架
Part-6. 敏捷：让架构设计敏捷起来
Part-7. 成功案例分享：
★ 案例_A：多机整合创新设计的案例分享
— 以创新型架构设计支持<软硬整合开发>
— 进而落实<硬硬结合销售>商业模式
★ 案例_B：插件(Plugin)管理机制的设计重构案例分享
— 重构的设计思考
— 从<重构设计>到<重构代码>
★ 案例_C：高老师的EIT造形与敏捷顶层设计经验分享
— 基于减法设计，让人们更有勇气面对复杂
— 透过迭代和反馈的去芜存菁，让人们更具有信心去经营未来、捕捉新机会
★ 案例_D：诸葛亮与麦肯锡的减法设计范例
— 诸葛亮的溯因推理&减法设计
— 麦肯锡的MECE设计思考
Part-1. 目标：从<稳定抽象>到<实践创新>
1.1 增添一个”合”设计元素
- 由于架构设计有两个基本技艺：抽象与组合(封装)；因此衍生两个不同的架构设计流派。
- 抽象(思维)派：抽象出稳定、可靠、不变的共同性架构。
- (创新)组合派：增添一个”合”元素，组合出具体独特性的创新架构：
- “合”元素的影响：以”组合”为目标，先定接口(Interface)来支持组合，并以接口包装内部的结构，让内部结构也是可以变动的，以便支持弹性地敏捷重构。
- 这(创新)组合派架构设计方法，就是本课程所称的：<创新型架构设计方法>。
1.2 让<目前决策>具有未来性
- 架构师的职责是致力于现在决策，并让它能包容未来的变化，也就是让<目前决策>具有未来性。
- 架构师不是去预测未来，不是去关心<未来决策>、或去替未来做决策。
- 未来环境是善变的、市场需求也往往如流水般不可测；也就是因为它的未来的不可测性，所以我们需要优越的架构设计。
- 例如上图所示，有两个软件模块：C(Client)模块与S(Server)模块；而且两者之间透过网络通信机制来互通。此时一般人会先去寻找标准的通信机制(如协议)，然后才开发C和S软件模块。这就是预测未来(通信途径)了，会让软件架构失去未来性，所以不是有效的软件架构设计思维。
1.3 让架构与代码(Code)两者能无隙缝衔接
- Kent Beck曾说：”代码是设计(Design)与现实(Reality)的明暗交会处”。
- 代码是架构的外貌：
- 为了让架构与代码两者能无隙缝衔接，高焕堂老师设计了EIT代码造形，让接口(Interface)的设计，能够直接落实到代码。
- 透过接口的落实为代码，及早检测(如TDD)，促进互联互通&信息共享。
1.4 让创意深深爱上需求(的限制)
- 抽象思维派：需求是架构设计的基础；所以又称为Requirement-based架构设计。这是Waterfall开发过程所仰赖的架构设计途径。
- 创新组合派：愿景是起点，创新组合是目标，需求用来检验；所以又称为Test-Driven架构设计；或TDD( Test-Driven Development)方法：
- 在TDD检验机制里，需求是架构设计的限制(Constraint)；而不是架构设计的基础。这反而让架构师获得更大的创意空间。
- 所以，谷歌公司副总Marissa Mayer提倡：“创意爱上限制”(Creativity loves Constraint)。她说：”创新来自愿景与限制的互动”(Innovation is born from the interaction between constraint and vision)。限制迫使架构师重新审视愿景(Vision)，从不同观点切入，寻找新事物；同时也让其聚精会神、厘清思路；非常具有创新性。
1.5 设计思考：从简单(来自设计&创新)里叫复杂(来自智能&联网)
- 需求善变的项目开发需要敏捷，敏捷需要搭配<创新组合型>架构设计师，架构师需要设计思考技巧，设计思考仰赖溯因(Abductive)逻辑推理能力。
- 溯因推理是由观察现象(结果)到原因的猜测推导过程，沿着现象的特征往回追溯产生该现象之原因；它是除了演绎推理、归纳推理之外的第三种逻辑推理方法。运用这种方法去猜测现象的可能原因，受逻辑规则制约的程度较小，具有高度的灵活性，是一种颇具创造性的推理方法。如下左图所示。
- 敏捷开发的幕后思维，就是 {溯因逻辑 + 迭代过程}。
- 在一个企业(或公司)里，程序员、架构师和高层经里三者之间有着”战术引导战略”的重要关系。经理与架构师之间是：战略-战术关系；而架构师与程序员之间也是：战略-战术关系。敏捷方法，让”战术引导战略”的机制实际运行起来，例如TDD对代码(战术效果)检验的反馈，带动了架构的重构(战略调整)。
- 传统上，关于”架构设计”往往比较重视”架构”而不是”设计”，因此对于设计思考、设计技术并不太重视；这常常导致：没有设计的架构。
- 设计，就是把一件复杂的事简单化，在把简单化出的形式(Form)，用事实(reality)和逻辑(logic)加以检验(verify)，最后，再以直觉把形与复杂本质结合在一起。
- 架构设计造形(如EIT造形)的<简单性>，提升了人们擁有面對软件复杂多变的能力；唯有熟谙此道，才能创造架构和产品的<未来性>，才能掌握未來意想不到的機會。
Part-2. 眼光：以新视角看日益复杂的架构
2.1 API = 话语权
- API与UI不同。
- UI是App与用户的交互接口。
- API则泛指软件模块间的接口，可分为：
- SI：本架构与外部系统之间的接口
- PI：本架构与内部挿件(Plug-in)之间的接口
- 一般API：本架构与应用程序(App)之间的接口
- 掌握API定义权，就拥有话语权。
2.2 应用框架 = 用来框住应用(App)的架构
- 框架的基本组成元素：EIT代码造形(Form)。
- EIT造形的<I>就是API。
- 框架是鱼饵，API是鱼钩。
- 鱼饵是送人的礼物；送越多，拥有市场版图越大。
2.3 框架(平台)调用App，不是App调用框架
- 用户并非直接碰触软件(App)。
- App在软件架构里，其地位是最低的。
- 例如，从移动终端发信息给云平台时，云端的IaaS层先接到信息；然后才(调用PaaS服务)来将信息往上送；再调用SaaS层服务来将信息送上去。
2.4 从<C/S API>到<端/云API>
- API是分工的界线。
- 过去，Client与Server是由不同团队分工开发的：
- 今天，谷歌、Facebook、微信等，改变了API、改变了分工，如下图所示：
- 这称为跨<云&端>强龙企业。
2.5 架构师做<分>的决策，开发者做<合>的任务
- 肯德基餐厅的厨师做：庖丁(分)解鸡。
- 肯德基柜台人员则做：组(合)出全鸡、半鸡等套餐。
- 分得妙、就合得快。
- 分：无之以为用；合：有之以为利。
- 因<分>而得接口(Interface)，依据接口而快速组<合>。
2.6 <分>的时间点：买主来到之刻
- 平台(Platform)设计者，必须重视买主，而不是用户。
- 买主来到之前，先做分(即无之)。
- 买主来了之刻，才做合(即有之)。
2.7 没钱就改版，改版就有钱
- 拥有平台(Platform)者，常采取分层(Layered)架构，适合理的。
- 过去，上层模快(开发者)，常常要求下层必须稳定不变。
- 今天，上层模块不能要求底层的稳定不变，而是要处处维护底层变动的自由度；这样才能实现：没钱就改版(底层)，改版就有钱。
2.8 如何跨(别人的软件)平台
- 除了大家熟悉的HTML5/JS途径之外，还有没有其它跨平台的模式呢?
- 目前的软件平台大多采框架(Framework)来提供API。
- 于是，我们的跨平台策略是：挾天子以令诸侯。
- 这将别人(平台)的API，改变成为自己的API，掌握了API就有话语权。
2.9 软件平台 + 通信网络平台
- 软件平台与通信网络平台是两的层级。
- 网络平台是以电信网络为中心，后端(云端)和终端各挂在网络的两端；两者都是网络平台的插件。
- 软件平台则想办法让网络被包容起来，反过来让网络成为软件平台的插件；这是为什么三网融合可能帮三个软件平台抬轿的原故。
- 这种架构设计的关键思维是：不能将软件切分为端与云两块，且当成网络平台的插件。
- 软件平台就像集装箱(Container)，将复杂的通信网络、硬件接口、内容格式等包装起来，呈现出简单外形，让人们感到这些事物的可爱、好玩好摸好抱。并没有删除外在事物(如冰箱等)的复杂。而只消除人们心中的复杂感觉，达到简化目的。
- 例如，Google公司的软件平台(含Android)正好横跨&控制整个互联网。
- 软件平台控制网络平台，而不是将软件切分为两块，分别挂在网络平台的两端：终端与云端。
2.10 项目管理：搭配敏捷(Agile)的跌代(Iteration)过程
- 架构的一生：架构的主人是愿景(Vision)，架构的生母是问题(Problem)，架构的养母是现实(Reality or Constraint)，架构的养份是设计师的创意(Creativity)，架构的外貌是代码(Code)，架构的情人是需求(Requirement)，架构的岁月是迭代(Iteration)。
Part-3. 抽象与组合：必备的思维、方法和模式
3.1 设计概念与技艺
概念复习
- 框架是计算机可执行的架构。
- 框架是当今提供API的只要机制。
- 深入认识控制反转机制。
- 主控者是框架，而不是应用程序。
- 框架的重要功能：提供默认行为(Default Behavior)。
技艺复习
- 抽象(无之)与衍生(有之)。
- 打造框架：细腻的抽象步骤。
- 基本步骤：
- 细腻的手艺(一)：数据抽象
- 细腻的手艺(二)：函数抽象
- 细腻的手艺(三)：将抽象类别转为接口
- 善用类的继承(Inheritance)机制。
- 设计基类的抽象函数。
- 抽象是手段，组合是目的。
UML图形
- UML的3种基本图表：类图、顺序图和用例图。
- 以UML表达设计模式和框架。
- EIT造形的两种表达：UML图和代码。
3.2 架构设计的需求分析方法
- 基本设计技能：把轮胎拔掉。
- 伟大的雕刻师罗丹( Musée Rodin)说：”把不必要的部分去掉”。
- 买主需求：想想为什么(why)汽车架构师会决定把轮胎拔掉呢? 其背后的理由是：买主来了，才知道买主对轮胎的偏好或特殊需求。只有等到买主决定和挑选了轮胎之后，才能将轮胎装配上去。
- 探索买主需求：
- 为什么把轮胎拔掉呢?
- 为什么火锅店的桌子要挖洞呢?
- 为什么餐厅要分开<食谱>与<点菜单>呢?
3.3 接口设计模式
如何定义接口(Interface)
- 在OOP里，将接口定义为一种特殊的类别(Class)。
- 在Java里，将”纯粹抽象类别”称为接口(Interface)。
- EIT造形的接口表示为<I>；<I>可以合并到<E>里。
- 被动型API与主动型API。
API与商业模式
- API决定控制权。
- 谁拥用接口的制定权，谁就掌握控制点，就能获得较大的话语权。
- 从API看控制力量的强弱等级。
EIT基础(一)：容易，插件容纳变化
- 什么是插件<T>?
- 插件(Plugin)的分类；插件与接口。
- EIT造形里的插件<T>。
EIT基础(二)：结构制约，积极掌控插件
- 什么是接口<I>? 谁控制<I>?
- 接口的分类。
- <I>决定控制权。
EIT基础(三)：组合创新，让整体<飞>起来
- 什么是平台<E>?
- <E>+<I> = 框架(Framework)。
- <E>是控制点，透过<I>来驱动<T>。
EIT基础(四)：曹操类，协天子以令诸侯
- 拿EIT造形搭配Proxy-Stub设计模式，规划Stub类别(曹操类)，制定自己的<I>，让<T>脱离上层<E&I>所牵制；实现”挟天子以令诸侯”的效果。
3.4 平台 = 框架 + 引擎
- 古典：平台 = (服务)引擎。
- 为了维护底层<引擎>的变动自由度，就采用新架构：
- 于是，得出典型的Framework-based平台架构：
- 当今的.NET、iOS、Android平台都是这种架构。
- App就是一种插件；应用层也是插件层。
Part-4. 范例：设计方法的应用实例解析
4.1 范例(1)：保护<DB引擎>的变动自由度
- 传统架构：降低引擎的变动自由度。
- 优化架构：加上一个EIT造形。
- EIT造形直接落实为类别(代码)：
- 此架构的控制点在哪里? myDbHelper类别是谁开发的呢?
- 此EIT造形与Factory模式有何差异呢?
- EIT造形如何保护DB引擎的变动自由度呢?
- SQLite引擎可以”没钱就改版，改版就有钱”吗?
4.2 范例(2)：后台<业务规则(BR)引擎>的挿件架构
- 首先替引擎设计一个EIT造形，并将成长为框架。
- 插件包括3种：App(用户)插件、业务(业主)插件和平台插件。
- 当插件增多了，需要设计插件管理机制。
- 看似复杂的架构，却只是3个EIT造形的巧妙组合而已。
4.3 范例(3)：如何搭配敏捷(Agile)或RUP的跌代
- 两种方法都是跌代(Iterative)的模式。
- 其实，两种方法也都是渐增(Incremental)的模式。
- 需求分析也都可以来自：双插式分析法。
- 依循I&I和Use Case-Driven途径，以 EIT造形来表示接口。
- 然后将EIT造形落实为类别和代码。
- 随着<领域概念>分析和<业务规则>分析，得到更多的业务概念、类别和规则，就以前面所述的<平台&插件>关系来组织和重构。
- 此架构模式，既能搭配敏捷开发，也能搭配RUP方法。
4.4 范例(4)：如何提供<插件接口>给Client
- 通常，后台的业务或平台插件的开发者，与Client开发者是不同的；而且开发的时间点也不一样(插件常开发在先)。
- 那么，当Client需要调用插件时，后台如何提工插件接口给Client开发者呢?
- 即使Client端可以从文件中得知插件的接口，又如何调用呢?
- 首先，后台<E&I>提供一个通用型接口，内含一个通用型函数；
- 然后，后台提供一个Proxy类别给Client：
- 那么，又如何提供Proxy类别的代码给Client开发者呢?
Part-5. 多层架构：如何在C/C++平台上建立Java框架
5.1 目的
- 让Client端开发者自己来撰写后台的插件。
- 于是，后台成为一朵真正的云(Cloud)了。
- 一个C/C++平台可以搭配多个不同语言的框架。
5.2 做法：以Java为例
- 使用JNI(Java Native Interface)。
- 例如，C/C++平台的<业务规则BR引擎>可以搭配一个Java框架。
- 因为C/C++模块(如<业务规则引擎>)可以调用Java函数，所以C/C++平台仍然拥有主控权。
5.3 也能用ANSI-C语言来设计框架
- 活用C语言函数指针(Function Pointer)。
- 在C语言的struct结构内定义一个数据项(Data Item)¸ 并定义其型态(Type)是函数指针。
- 这个struct结构相当于C++的抽象类别了，而函数指针数据项，就相当于是抽象函数了。
- 于是，就可以撰写这个struct结构的”子类别”(或插件)了。
Part-6. 敏捷：让架构设计敏捷起来
6.1 敏捷与架构的完美组合
- 敏捷开发的原则和价值观。
- 开发、架构、测试之关系。
- 过程观点：(需求)测试做<反馈>，敏捷(过程)做<迭代>。
- 分合观点：(架构)设计做<分>，(代码)开发做<合>。
- 测试触发反馈，反馈带动迭代，迭代驱动<架构à代码>重构。
- 迭代促进了<架构师&开发者>的心灵沟通与携手协作。
- 举例：架构师如何设计敏捷的起始架构(Simple Solution)
- 加法设计：围绕问题( Problem)和愿景(Vision)，产生创意构想(Creative Idea)。
- 减法设计：创意爱上限制(Creativity loves constraint)。
6.2 代码是架构的外貌，永远青春
- 架构是软件的骨架、代码是软件的外貌。
- 架构是软件的核心。
- 架构的用意：创新组<合>。
- 架构设计的焦点：接口。
- 设计决策具有<未来性>，系统才能适应未来。
6.3 设计与开发的分工合作
- 架构设计的目的是：组合。
- 架构师做<分>，支持开发者做<合>，合作实践(系统)组合。
- 架构师的核心工作：接口设计(Interface Design)。
- 开发者的核心工作：依据接口，开发(系统)模块并整合。
- 有许多种开发者：如App开发者、底层系统开发者等。
6.4 敏捷思维：尽快呈现架构的外貌
- 接口设计是<物>的组合设计。
- 接口设计是<事>的分工设计。
- 架构师设计多种接口来支撑分工与组合。
- 依循敏捷原则，接口迅速落实为代码，尽快呈现外貌。
- EIT造形：呈现核心设计的外貌。
6.5 一群<E&I>美妙的组合是：框架(Framework)
- 随着敏捷的迭代过程，EIT造形会逐渐增加。
- 如何巧妙组合渐增的EIT造形：擅用设计模式。
- 组合起来，就成为软件框架了。
- 如何迭成多层级(Layer)的框架体系：以Android为例。
Part-7. 成功案例分享
◆ 多机整合架构设计与新型商业模式
★ 详细请看：多机整合创新设计的案例分享
– 以创新型架构设计支持<软硬整合开发>
– 进而落实<硬硬结合销售>商业模式
◆ 应用框架的插件管理架构设计
★ 详细请看：插件(Plugin)管理机制的设计重构案例分享
– 重构的设计思考
– 从<重构设计>到<重构代码>
◆ 造形、方法论的设计思考
★ 详细请看：高老师的EIT造形与敏捷顶层设计经验分享
– 基于减法设计，让人们更有勇气面对复杂
– 透过迭代和反馈的去芜存菁，让人们更具有信心去经营未来、捕捉新机会
◆ 溯因推理&减法设计
★ 详细请看：诸葛亮与麦肯锡的减法设计范例
– 诸葛亮的溯因推理&减法设计
– 麦肯锡的MECE设计思考
~ end ~
