面向对象架构设计流程

2019独角兽企业重金招聘Python工程师标准>>>

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度评估”的方式
• 架构设计的第二个难点是选择架构方案，可以采用“优先级选择策略”的方式

转载于:https://my.oschina.net/jimilee/blog/727861