架构设计的几点思考

软件架构的意义

软件架构的意义是什么，有不少不一样的理解和争议，这里不想就软件架构的意义给出完整的定义，而是想聊聊其中的一点：软件架构是沟通 (Architecture is communication)，关于软件架构的更多意义，建议参考这篇别人的旧文。

为何软件架构意味着沟通呢？由于软件工程自己是一个组织一群人为了一个问题进行创造性劳动的过程，由于软件工程自己的特色，因此沟通的重要性是软件工程区别于传统工程的一个显著特色。关于这一点，我以前的帖子已经解释过，这里再也不展开。

什么样的架构有利于沟通呢？

在回答这个问题以前，咱们先来看一张图。

若是汽车设计师经过这张图来向其余人解释汽车是什么的时候，我想除了相关的专家不会有人可以轻易理解每一个部件在整个汽车中的用途，以及他们是如何在一块儿工做的。

为何呢？在《金字塔原理》这本书里提到，人一次可以理解的思想或者概念的数量是有限的，因此若是须要表述一个复杂的思想时，须要经过金字塔的结构来组织整个表述。回到软件架构来讲，其道理是相似的，为了让咱们的架构设计更好地让你们理解，能够经过一个金字塔的形式来组织咱们的架构设计，事实上咱们也是这么作的。

因此下图可能可以让咱们更加容易理解一辆车是如何组织的（这张图也来自网络，不彻底匹配本文，见谅）

软件架构中的具体问题

从上面的例子以及咱们实际的经验来看，金字塔型的结构确实是一个很是有效的沟通组织方式，那具体应用到软件架构来讲，有哪些具体的问题和解决思路呢？

何时须要拆分？

软件架构设计中常常碰到的一个问题就是，何时须要拆分，包括分红不一样的模块，应用或者系统？关于这个问题，很难找到一个直接的答案，可是咱们能够侧面来回答这个问题，也就是团队组织是否须要拆分。我的的建议是要考虑的是问题的复杂度和人之间的关系，当一个问题的复杂度大到一个小团队（参考亚马逊的two-pizza team理念）都没法承接的时候，咱们须要考虑将其拆分红多个系统或应用，当一个问题的复杂度大到一个工程师在平常工做中没法承载的时候，则应该拆分红不一样的模块或应用。由于现实中问题的规模自己就是模糊的，因此这里没有明确的量化指标，具体的拆分还须要考虑复杂度之外的因素，这里只是强调一下，拆分的原则是须要首先考察问题的复杂度。

要不要引入抽象层？

关于引入抽象层的时机，须要从两个角度来考虑，一方面是须要放在一块儿讨论的事物或者概念的数量大于普通人所能接受的范围时（神奇的数字7±2），咱们可能须要考虑抽象层。
另一方面就是当明显不在同一个抽象层面的事物摆在一块儿讨论的时候，好比说下面就是一个错误的例子：

发动机 车架 底盘 轮胎 示廓灯
一个简单的判断标准就是看看这些事物可否按照同一条规则来分类，而且共同组成高一层的抽象概念，若是不能的话，每每就是咱们把不一样层面的事物摆到了同一个抽象层面上。

何时共享？

共享或者说复用是软件工程师最喜欢的概念之一，可是实际上不少时候咱们想复用却复用不了，或者复用自己带来了比较大的成本。复用的关键因素在于对于问题和解决方案适当抽象，具体来讲一方面咱们须要确保解决问题所须要的能力都能经过抽象接口(interface)展现出来，也就是说接口的能力必须是完整的，同时这个抽象可以屏蔽掉无关的细节，也就是尽量地简化。

因为实际的问题错综复杂，而且咱们在描述问题的时候有不少模糊的名词，因此一个常见的误区在于咱们一般会混淆两个看起来相似可是有不一样实质的问题，好比汽油发动机和柴油发动机虽然只差了一个字，可是其结构和原理是彻底不一样的。这个例子虽然很好理解，可是实际工做中咱们却仍是会由于名字相近就把不一样的问题放到一块儿去考虑，这里就不展开了。

通常来讲，当咱们可以清楚而精确地定义一个问题的时候，就是一个产品可能被共享的时候。在考虑一个产品是否能被共享的时候，咱们不要被问题域的名词所迷惑，必定要从其对应的抽象模型，包括具体的行为方式和特性来肯定两个问题的实质是否同一个问题，两个问题可否真正使用同一套模型来描述和解答。

问题的核心和边界

咱们的一个常见的作事方式就是求大求全，却没有清晰的关于问题核心和边界的概念，经常突破产品所在的抽象层次，看起来是带来了更多的能力，实质上倒是破坏了整个架构的设计，模糊了各个概念的边界。因为潜在使用者没法理解这样的组件对应的问题，同时也担忧其潜在的复杂逻辑关系，致使了这样的组件反而很难被复用。

我以为在软件设计的过程当中，咱们必定要想清楚问题的核心是什么，边界是什么。为了解决一个问题，咱们所须要的最小的抽象模型是什么？在服务化的架构理念里，当咱们可以给出一个尽量简单而有效的服务时，才更有可能在更广阔的场景下使用这个服务。

业务架构和技术架构？

在我看来，须要咱们讨论的问题的是业务架构，或者说从服务化(SOA)的角度来讲，咱们更多地要考虑的是问题域和问题所对应的解决方案。这里所说的业务，不彻底是整个公司对外提供的产品，也包括每一个服务自身的对其余服务和产品输出的能力。换句话说，当一个团队明确了一个须要解决的问题的时候，这个问题就是就是这个团队的业务，而这个问题的解决方案的模型和表述，就是咱们的软件架构自己。

至于咱们经常谈到的技术架构，在我看来不少时候是一个比较模糊的概念，不少时候咱们的技术架构仅仅是对于中间件和数据库技术的选择，当咱们所须要解决的问题以及相应的方案都基本肯定的时候，具体技术方案的选择相对来讲是争议比较小的部分，这样的技术架构没有太多须要讨论的内容。对于另一些技术架构，同时包含对于技术栈和系统逻辑关系的描述，后者大多均可以融合到咱们的软件(业务)架构设计中去。

由于菜鸟业务的复杂性，如今已经很难有人可以对于全部的组件都有比较深刻的了解，而每一个业务线的同窗都会对本身所在的业务线有更加深入的理解，因此我建议技术部架构委员会更多地能够关注以下几个问题：

• 如何让同窗们给出比较合理的问题模型和相应的系统架构，而非具体某个产品的系统架构
• 处于抽象层次上层的架构，也就是说重点关注和讨论大的系统分工和边界
• 系统和服务复杂度的合理性，包括团队规模的合理性

本文做者：行易

阅读原文

本文为云栖社区原创内容，未经容许不得转载。