面向对象架构设计流程

1. 引言

架构设计，一个看起来很牛B的名词....

架构设计师，一个很牛B的职位.....

在绝大部分公司里，架构师就是技术人员的终极方向，是技术金字塔的顶端。

因此，当咱们看到一个架构师或者听到一个架构师的名字时，是否是会情不自禁的肃然起敬，心底油然的产生一股敬意？

在不少人眼里，架构就相似于艺术家，他们拥有非凡的才华，创造了一个个优秀的产品，并受到人们的尊敬，成为了行业大牛，今后走向人生的巅峰！

但架构设计真的就这么神秘和神奇吗？咱们这些普通人难道就注定和架构设计无缘了？

实际上，没有什么神秘和神奇，也不须要具有艺术家的才华，只要掌握适当的方法，一步一步的逐步完善，菜鸟也可以作架构设计。

2. 面向对象架构设计流程

架构设计实际上是“面向对象”的思想的具体应用而已，那我么来看看如何以面向对象的思想来指导架构设计。参考“面向对象技术流程”的作法，咱们一样也总结出一个“面向对象架构设计流程”，把架构设计分为几个环环相扣的步骤：业务架构——领域架构——软件架构。

2.1业务架构设计

和“用例模型”相似，主要用于描述客户的业务整体结构。与“用例模型”不一样的是，业务架构更抽象，更高一层，只关注总体的业务流程，不关注具体的业务需求细节，不须要考虑异常处理、替代处理等场景。

2.2 领域架构设计

和“领域模型”相似，主要用于从“业务架构”中提取出来“领域架构”，为后面的进一步架构设计作准备。

2.3 软件架构设计

和“设计模型”相似，基于“领域架构 ”，应用架构设计原则和方法，精雕细琢，逐步迭代，得出最终的软件架构。

有了这同样的一个流程，原来看来颇具艺术色彩的架构设计，其实就变成了一个标准化的加工过程，只要循序渐进，一步一个脚印，即便是菜鸟，也能够作出一架构 。

但也千万别认为架构设计就垂手可得了，就像一样的岩石、一样的模型，不一样的雕塑家获得最后的做品也会相差很远同样，架构设计流程只是保证咱们可以作出一个可用的架构，是否可以作出一个优秀的架构，与架构师的水平、经验有很大的关系，既须要架构有必定的创造天分，又须要架构师有深厚的积累。

3. 架构设计实例

3.1 全新的业务系统

在中国神话中，盘古大神开天辟地，在盘古开天辟地以前，天地不分，没有山河湖川、风雨雷电.....世界处于一片混沌状态！而对于架构来讲，刚开始面向的也是一种混沌的状态。

由于，咱们面对的也是一堆客户提的需求，看到只是一篇或多篇文字描述的需求文档，运气好的话，需求文档可能会条理清晰、逻辑清晰;运气很差的话，也许这些文档杂乱无章。有时候，甚至一篇像样的文档都没有，只是简单的几句描述性的话。

无论怎么样，咱们都须要从无到有创造出一个架构，而咱们所拥有的只是客户需求，多是通过分析的，也多是最原始的。

怎么办？

拍脑壳拍出一个？这跟猴子调皮敲键盘敲出《莎士比亚全集》的概念可能差很少。找个艺术家来创造？可是艺术家却不懂计算机。随便画几个圆圈再加几条线？画得不对怎么办？冥思苦想，看起来是没有办法了，但有句话说的好“蓦然回首，那人却在灯火阑珊处”，其实咱们忘记了最重要需求来源：客户需求。

你必定会惊讶:客户需求里面有架构？这不是在忽悠吗？前面还说需求可能杂乱无章，怎么这里就说客户需求里面有架构？

由于，无论什么架构，最终都是要实现业务需求，不能天马行空地创做，不能脱离业务范畴去作架构设计，而是要受到业务的约束，借用如今互联网流行的一句话:情怀落不了地，就是矫情。无论是条理清晰仍是杂乱无章的需求，架构的雏形都隐藏在里面，咱们须要的是透过纷繁复杂、千丝万缕的需求来发现它，而这也是架构师的价值所在。

咱们知道，即便客户不提需求给咱们，客户的系统也已经在运做，这不是由是否使用计算机决定的，而是客户的业务领域决定的。

举个简单的例子，美国第一条铁路诞生于1830年，至今已经走过200年的发展历程了;纽约证券交易所成立于1863年，至今已经接近150年了;而第一台可以进行复杂运算的计算机于1940年才制造出来。

那么在计算机诞生以前，难道美国铁路系统和纽约交易证券所就不能运转了吗？显然不是这样的，在计算机诞生以前 ，美国铁路系统和纽约证券交易所确定也是一个完整的可运行的业务系统，可以知足人们的相关需求。

计算机只是一个工具而已，能让客户的业务系统更加高效，更加智能、更加快速地运行，但毫不是计算机创造了客户业务系统。所以，架构设计最初的来源就是“客户业务系统”。

怎么知道客户业务系统呢？最简单的方法固然是问客户了。

有的人可能以为这个太简单了，还想知道是否还有其它更加牛B的方法。

事实上这是最简单可是最有效的方法，也是最不会出问题的方法，虽然不牛B！

由于客户的系统是客观存在的，是已经通过实践检验和验证可行的系统，你不可能帮客创造出来另一套业务系统;并且，客户的系统客户最了解了，客户是最好的信息来源。

也许你会说，若是有类似的业务系统，我照搬过来稍作修改是否能够呢？

看来很不错，只要找个相似的系统，微创造一把就能够了，省时，省力又简单！

但谁能保证你所理解的类似就是和客户业务系统一致呢？谁也不能保证，所以，类似的系统只能作参考，不能照搬。咱们只能站在巨人的肩膀上，但不能将巨人搬走。

固然，不少时候架构师面对的并非最终的客户，而是公司的市场人员或者需求分析人员，这时候最好的方法固然是问"需求分析"人员了。

在理想状况下，优秀的需求分析人员对客户业务系统了然于胸，有时候甚至比客户还要更加清楚，由于为了理解业务系统，需求分析人员可能须要和客户的各类人员交流(例如经理、员工等)，获取的信息更加全面。

固然，碰到不理想的状况，需求分析人员对客户的业务系统不了解，那么也很简单：提出你的问题，让需求分析人员向客户了解清楚。

幸运的是，大部分客户的业务系统已经自然的分为几个部分了。咱们能够简单的举几个例子(只是为了简单说明，实际的客户业务系统应该比这个复杂多了，仅做参考)。

• 沃尔玛:至少包括"仓管"、"物流"、"店面"、"支付"等几个部分。
• 中国铁路售票系统：至少包括"订票"、"查票"、"支付"等几个部分。
• 一个网店业务系统：至少包括"商品"、"订单"、"客服"等几个部分。

架构的最初雏形就是源自于客户的业务系统，简单地说，最初的架构设计就是对客户业务系统的模拟！ 所以，咱们不需求天才的创造能力，也不须要拥有艺术家的才华，只须要掌握一个很是重要技巧“问客户”，就可以获得最初的架构雏形了。

3.2 已有的架构优化

除了全新的建立一套系统外，还存在另外的一种状况：已经有了一套系统，但客户不满意，提出了新的需求或者更高的需求。这种状况其实很简单，新架构的基础就是架构，而后在已有架构上设计出新的架构。

你也许会担忧这样作的话，新架构是否会受限于已有的架构？

这里关键是要看客户提出的新需求或者更高要求是否改变了客户的业务系统，若是是，则可能须要建立一套全新的系统;若是只是对已有的系统进行加强或者调整，则在原有架构上进行调整便可。

幸运的是，不多客户会直接提出一个颠覆性的需求或改变，缘由很简单，客户业务系统变动也是按部就班的，颠覆性的变化 ，客户的业务代价也会很是大！

4. 业务架构实例

假设在一个未知的星球上，有电视，电话机，但就是没有电脑，如今咱们要在这个星球上建立一个电视购物商城，名叫“星球商城”，则星球商城的业务架构能够简化以下：

• 星球商城在电视上投放商品广告;
• 客户经过看电视，获取商品信息;
• 客户打电话给商城的客户人员下订单;
• 商城的客服人员收到订单后，客户人员打电话给仓库管理员下出货单;
• 仓库管理员生成出货单，安排物流人员送货;
• 客户收到货后，支付款项给物流人员;
• 物流人员收到款项后，将出货单和款项交给结算中心结算;
• 结算中心确认发货单和款项无误后，记录订单，订单完成;

通过上面的简单例子咱们能够看出，就算没有电脑，这个未知的星球上的商城依然能够正常运转。虽然这个例子比较简单，但已经基本上将一个电视购物商城的业务架构描述清楚了。

须要注意的是，业务架构和用例模型同样，其实也是用文字进行描述，但比用例模型更加的抽象，也不须要关注各类异常或者分支处理流程，只须要关注描述业务的总体结构便可。

和需求分析是咱们须要关注需求的“结束和限制”同样，业务架构除了关注业务自己的流程外，也须要包含业务的结束和限制。

以商城为例，咱们能够获得商城架构的一些业务结束和限制：

• 性能：每秒可以处理10万个订单;
• 成本：整套方案预算不超过10000万元;
• 可靠性：可靠性99.999%，整年中断服务时间为5分钟;
• 技术性：必须用JAVA技术;
• 兼容性：必须与公司的其它系统兼容;

千万别小看这些看似简单的结束和限制，它们在架构设计的过程当中起着很是重要的做用，由于它们是架构迭代的驱动力。若是说知足业务的功能需求是基本要求，那么知足业务的约束和限制则需求才是合格的架构。

5. 领域架构实例

有了客户的业务系统后，咱们只须要稍微提炼下，就能够获得一个领域架构。具体的提炼方法以下：

• 提取业务模块
• 肯定业务模块之间的关系

以上面的商城为例，咱们能够这样提炼业务模块。

• 星球商城在电视上投放商品广告，提炼为“广告”。
• 客户经过看电视，获取商品信息，提炼为“商品”。
• 客户打电话给商城的客户人员下订单，提炼为“订单”
• 商城的客服人员收到订单后，客户人员打电话给仓库管理员下出货单，仓库管理人员生成出货单，提炼为“仓库”。
• 仓库管理员生成出货单，安排物流人员送货，仓库管理人员生成出货单，安排物流人员送货，提炼为“物流”。
• 客户收到货后，支付款项给物流人员，提炼为“支付”。
• 物流人员收到款项后，将出货单和款项交给结算中心结算，结算中心确认发货单和款项无误后，记录订单，订单完成，提炼为“结算”。

提取业务模块后，咱们再提炼业务模块间的关系，例如：

• “广告”模块、“订单”模块、“仓库”模块都须要从“商品”模块获取“商品信息”。
• “订单”模块下单给“仓库”模块。
• “仓库”模块生成出货单给“物流”模块，“仓库”模块还须要将订单信息同步到“结算”模块。
• “物流”模块将出货单和款项给“结算”模块。

有了以上的分析和提炼，咱们就能够获得这样一个简单的领域架构 ，以下图所示：

6. 软件架构实例

5.1 第一步：照猫画虎

有了业务架构后，接下来就是最关键的一步：从业务架构转换到软件架构。虽然这是最关键的一步，但有了领域架构后，咱们的工做就容易多了，甚至有点容易得让人难以想象，咱们只须要在领域架构的基础上将各个模块映射为子系统便可。例如：将"订单"模块映射为“订单子系统”，将“物流”模块映射为“物流子系统” ......彷佛咱们啥都没干，就是加了“子系统”三个字。领域架构映射为初始的软件架构图以下图所示：

不过，咱们千万别小看这么一个简单的步骤，加上“子系统”三字后，咱们就知道设计哪些相关的软件子系统了，初始的软件架构就基本造成了，是否是很神奇呢？

这样的架构是否足够了呢？不少人可能都会马上说：“这样确定不行”架构设计怎么会这么简单呢 ......但实际上这个架构在某些场景下是可行的。例如，咱们天天只须要处理100个订单，那么这个架构足够了；每一个子系统都是一个独立的软件，每一个子系统都部署在一台机器上，这样是彻底可行的。

可是更多的场景下这个架构就不可行了。例如：咱们每秒须要处理10万订单，那么上面提到的“一台机器”+“一个软件”显然是撑不住的，由于单台机器、单个软件系统的处理能力达到每秒10万个是很难的(若是大型机之类的机器 ，处理性能会高一些，但也是有系统瓶颈的)；又例如，咱们须要系统的宕机时间一年不超过5分钟，那么“一台机器”+“一个软件”的架构显然 也支持不了，由于单台机器一旦出现故障，换台机器从新部署修复不止5分钟，也就是说存在单点故障的问题。

综合上面的描述能够看到，同一个架构，有的场景可行，但有的场景不可行，那么实践中究竟如何判断架构是否可行呢？

其实也没有什么玄机，就是看架构是否知足业务需求，但须要注意的是这里的业务需求包含两部分：功能需求和质量需求。只有同时知足这两类需求才算是可行的架构方案。

按照这个标准来衡量，咱们能够发现这个架构虽然知足了商城的功能需求，可是不能知足商城的质量需求，包含性能和可靠性都没法知足，由于这是一个不合格的架构。为了使最终的架构可以知足业务质量的需求，咱们还得须要继续努力(革命还没有成功，同志仍需努力 )。

5.1 第二步：按图索骥

有了领域架构映射过来的初始软件架构，业务的功能需求已经可以知足了。可是，业务的质量需求可能还没法知足，所以第二其实就是为了设计出可以知足业务质量需求的架构。

业务需求质量属性有不少，例如：“性能”、“可靠性”、"成本"等，这么多的质量属性咱们如何下手呢？很简单，哪里不足就从哪里下手。

咱们仍是以上面的商城为例，在实始的软件架构中“订单子系统”没法知足每秒处理10万个订单的需求，那么咱们就须要从这个点入手，看看如何可以知足这个性能需求。

一种很直观的方法就是增长机器 。例如，咱们能够用10台机器来完成“订单子系统”的功能，那么每台机器每秒只须要处理1万个订单，这个数据是合理的；若是还担忧有问题，那么干脆设计20台机器来完成“订单子系统”的功能，这样每台机器每秒只须要处理5000个订单，基本上是没有问题了。最终的架构图以下所示：

另一种方法就是将“订单子系统”再拆分为更多的子系统。例如，咱们能够将“订单子系统”再拆分为“接单子系统”和“下单子系统”、“商品查询子系统”，每一个子系统再按照业务质量的属性去评估，若是不知足则继续按照“哪里不足就从哪里下手”的思路和原则进一步的设计。好比，通过拆分后咱们发现“接单子系统”在一台机器的状况下仍是没法满“每秒处理10万个订单”的需求，那么也能够将“接单子系统”设计为10台机器来完成功能；考虑到“下单子系统”能够慢慢处理“接单子系统”生成的订单，“下单子系统”就继续使用一台机器完成便可；“商品查询子系统”也是相似的。最终的架构图以下所示：

以上样例只是为了知足性能需求而采起的方法，其实无论是什么质量属性，基本上都有一套比较成熟和固定的架构模式，这就是“按图索骥 ”步骤的由来——识别不知足质量需求，找到这个质量需求对应的架构模式，质量需求就 “图”，架构模式就是“骥 ”。

第二步看起来很简单，但实际上有两个隐藏的假设条件 在里面。

1. 架构师可以判断在初始架构中哪里可能不知足需求 好比上面的样例中，架构师知道一台机器没法知足每秒处理10万个订单的，可是能够每秒处理5000个订单；而普的开发人员不必定知道这个限制。

2. 架构师知道有哪此架构模式能够解决咱们遇到的问题 好比上面的样例中，架构师须要知道能够经过添加机器来知足性能需求，或者拆分系统来知足性能需求。 要作到以上两点，没有放之四海皆准标准作法，而主要是依靠架构师的经验和积累，并且同一个架构师的经验和积累，换个行业可能就彻底不适应了。由于是依靠经验和积累，因此架构师会以为这些作法是理所固然，顺手拈来；但对于一个则入门的程序员来讲，就会以为架构师很牛B、很厉害。

5.3 第三步：深思熟虑

到目前为止，咱们的架构设计一直是顺风顺水的，没有遇到 什么挑战和困难，但若是觉得架构设计真的这么简单就太天真了，前面的各个步骤都是准备工做，真正的挑战从这一步开始——万里长征，始于足下。“

那么具体是什么挡路呢？这个步骤的名称“深思熟虑”已经很好的归纳了两个挑战：“深思”和“熟虑”的具体含义以下： - 深思：全面评估各个备选方案的优缺点 - 熟虑：挑选最优的方案

5.3.1 深思：评估方案

在第二步”按图索骥“中，咱们以商城为例，给出了两个高性能的解决方案，但在实践中确定不可能两个方案都作一遍，只能挑选其中的一个方案来实施。那么问题来了：高性能的方案如何选择？哪一个方案强？

若是单纯从高性能的角度来评估两个方案，两个方案都可以知足高性能的需求，那是否意味着咱们像抓阄同样，随便选一个就能够了呢？

这个老是就涉及了架构设计的第一个难点：如何评价方案的优劣？

抓阄是确定不行的，凭感受和碰运气差很少，凭经验有点虚，没有把握，有没有一种方法既可以有理有据，又可以简单易行呢？

有，这就是方案”360“度评估，或者叫”综合评价“。具体的方法为：评估方案的多个质量属性，而后进行选择。

这里咱们仍是以商城为例，对比两个高性能的架构方案，以下表所示：

注：以上表格能够根据须要添加更多的对比维度，此处只是为了简单起见只对比了5个维度。 有了以上这样一个“360度评估”表格，方案的优劣点一目了然，咱们不再用瞎猜、瞎蒙或碰运气了，真正作到了“有理有据，简单易行”。

5.3.2 熟虑：挑选方案

咱们虽然可以从“360度评估”表格一目了然地看到各个方案的优劣点，但这样一个表格也只能帮助咱们分析各个备选方案，仍是没有告诉咱们具体选择哪一个方案。那么如何选择方案是否也有“有理有据，简单易行”方法呢？。

这个问题就涉及了架构设计的第二难点：如何选择方案？

有人可能看到“360度评估”表格，可能会觉得“哪一个方案优势多就选择哪一个方案”。这样确实很简单，但实际操做并不彻底可行。缘由一是一样的质量属性，不一样的业务和团队要求不同。好比上面表格中的”成本“和”复杂性”两个质量属性，若是是外包公司可能很是注重成本，而互联网公司更加的注重业务的迭代速度；缘由二就是有时候可能会出现两方案的优缺点个数都是同样的，好比上面表格中的方案1和方案2，在这种状况下没办法分出胜负。

既然不能简单地以数学运算来决定方案的优劣，那咱们就须要找到更靠谱的方法。这个方法就是“按优先级选择”，即：优先选择咱们最关注的质量属性表现占优的方案，若是两个方案在最关注的质量属性上表现一致，那么就继续比较其它关注的质量属性，以此类推，最后挑选出符合咱们心意的方案。

按照这个方法，即便是外包公司也能够优先选择“成本低”的方案，而互联网公司也能够优先选择“复杂度”低的方案1。

直到这一步，咱们才算最终的肯定了架构的方案。

7. 总结

• 架构设计流程：业务架构——>领域架构——>软件架构
• 业务架构隐藏在客户的需求里面
• 业务需求分为功能需求和质量需求
• 质量需求是架构设计的驱动力
• 领域架构是业务架构和软件架构的桥梁
• 领域架构能够直接映射为初始的软件架构
• 质量属性有一套相对应的架构模式
• 架构设计的第一个难点是评估架构方案，能够采用“360度评估”的方式
• 架构设计的第二个难点是选择架构方案，能够采用“优先级选择策略”的方式