什么是系统架构师？

系统架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。一个架构师得需要足够的想像力,能把各种目标需求进行不同维度的扩展，为目标客户提供更为全面的需求清单。

架构师在软件开发的整个过程中起着很重要的作用。

如何才能成为系统架构师？

1. 首先必须具有丰富的软件设计与开发经验，这有助于理解并解释所进行的设计是如何映射到实现中去。

2. 其次要具有领导能力与团队协作技能，软件架构师必须是一个得到承认的技术领导，能在关键时候对技术的选择作出及时、有效的决定。

3. 第三是具有很强的沟通能力，其实这一点好像什么角色都最好具备，软件架构师需要与各路人马经常打交道，客户、市场人员、开发人员、测试人员、项目经理、网络管理员、数据库工程师等等，而且在很多角色之间还要起沟通者的作用。

而设计图，它不是简单的供你欣赏，他其实是架构师，产品经理，开发工程师，测试工程师等各种角色之间进行沟通的语言，沟通的一个桥梁，让整个团队更能有效的协调工作。

设计图不单单是架构师要掌握的，在一个产品的开发过程中，任何一个环节，任何一个角色都可以通过掌握不同的设计图来完成沟通的。

流程图

流程是一系列的逻辑关系（包含因果关系、时间先后、必要条件、输入输出）产品经理做需求前一定要先把这些逻辑关系理清楚，如果非要用一句话概括的话“流程就是在特定的情境下满足用户特定需要的总结”。

图就是将你头脑中的逻辑关系以图形化的形式呈现出来，具有图形化、可视化的特点，因为是图，你可以像你的版本迭代一样，当你的逻辑需要修改的时候拿出来迭代一下，同时因为有图，你还可以更好的给项目成员进行宣讲。

产品中设计的流程图主要有三种，业务流程图、任务流程图、页面流程图，下面我们来一一介绍。

业务流程图

业务流程图又称为泳道图，就是描述那些个体在什么条件下做了什么事情，他们之间有何关联。主要分三个方面：

1. 涉及到哪些主体？

2. 每个主体都有哪些任务？

3. 各个主体之间怎么联系的？一般涉及到多个主体，每个主体之间有联系。

任务流程图

泳道图一般是从战略上分析整个业务流程，让你对公司所做的业务有个大概的了解，而任务流程图就是在你的产品操作上，用户通过什么样的操作来完成它的目标，比如你去银行ATM机器上取钱，你是如何一步步操作把钱取出来的。

页面流程图

如果说业务流程图帮助你梳理战略，任务流程图帮助你梳理用户操作行为（主要给程序员看）、页面跳转流程在帮助你梳理各个页面之间的跳转关系（主要给UI和前端程序员看）这是一个逐步从整体到局部，从后端到前端的过程。

 

所有的产品都是由页面组成的，不论是APP、PC、H5都是由一个个页面组成的，页面流程图描述完成一个任务需要经过哪些步骤，你在画图的时候只需要清晰的表现出用户点击页面的什么地方，然后跳转到那个页面。主要由页面、行动点、连接线组成。

UI设计图标注

对于APP的页面，UI设计师会给出UI设计标注图，这样APP客户端开发人员，直接按照标注图进行页面的开发了。

 

产品设计完成后，架构师需要对产品进行软件的架构设计。包括技术的选型，模块的划分，开发人员的任务分配，工作量的评估等等…..

系统架构设计图

构架将在一次又一次迭代中不断演化、改进、精炼。

 

序列图

架构师一般在做详细设计的时候，会把程序模块之间的每一步调用过程很详细的画出来，这样开发人员拿到设计文档，就能直接开发。

类图

 

设计图有很多种，还包括用例图，状态图，活动图…… 不再一一介绍。画什么样的设计图，不是绝对的，不同公司，不同项目，需要画的设计图也是不同的，有些项目需要画原型图，有些项目只是对外提供服务，没有页面也就不需要画原型图。另外还要根据项目的工期，预算等等因素考虑。如果一个项目的工期也就一个月甚至更短，那基本上就是怎么简单怎么快就怎么做。

画图工具

‘工欲善其事,必先利其器’，下面就为大家介绍几款常用设计图绘制工具。以下软件都可以在微信公众号，回复“设计”，获取破解版本。

Visio

是微软推出的一款流程图绘制工具，它有很多组件库，可以方便快捷的完成流程图、泳道图、结构图的绘制，但是不支持mac电脑。

 

OmniGraffle

Mac下没有Visio很多人就用这个，这个一般流程图都能绘制，但是效率感觉没有Visio高，优点就是画出来的图形比较美，同时支持外部插件，缺点就是没有比较好的泳道流程图插件，画起泳道图来不是太方便，但也可以画，可以自己组装泳道。

另外一个缺点是收费的，只能免费试用15天，不过我已经为大家准备好了一个最新的破解版本。

 

ProcessOn

是一款网页版的在线作图工具，优点是无需下载安装、破解这些破事，同时支持在线协作，可以多人同时对一个文件协作编辑，而且上手比较容易，它提供很多流程图模版，可以方便的画出流程图、思维导图、原型图、UML图，缺点就是在绘制泳道图需要增加泳道的时候，只能在最后一列加入，不能在中间加入这一点有点麻烦，还有要吐槽的就是由于是在线的，有时候导出图片，导出来的并不太好，流程图画的大的时候也无法截图。

在线地址：https://www.processon.com

 

Axure RP

这是一款产品经理经常用来画原型的工具，它可以在页面里定义各种按钮点击事件，进行页面的跳转，模拟提交的过程，所以非常方便使用。画人物流程图的时候也可以用，但是要画泳道图、UML图的时候，没有对应的模版，需要自己画，效率不高，如果你觉得画原型，制作文档都在Axure里，不想来回切换软件的画，可以在里面自己制作一个组件，下次直接调用。

Axure RP是可以画出这样效果的原型图

 

PxCook

一款还不错的标注工具.

优点：

1. 成熟：跨平台——支持Windows和Mac

2. 成熟2：支持PS和Sketch。

3. 交互特别智能，也方便，一拖一放就标注完了。

4. 相当需要说的一点：对于PSD文件或者Sketch进行了修改之后，PxCook里的标注会自动进行更新，免除了手动操作的过程。这是后面很多软件没有的。

5. 支持移动设备的多单位切换。

缺点：

1. 不能支持多个文件同时进行标注。

2. 对于图层样式等信息，不能进行详细查看。

​

iThoughtsX

一款优秀的思维导图工具

 

OmniPlan

最NB的项目管理流程软件，OmniPlan旨在帮助您可视化，维护和简化您的项目。分解任务，优化所需的资源，控制成本，并监控您的整个计划，都一目了然。协作与您的同事和分享每一个细节，更新日历与你的天关，或混搭。接受和拒绝一次过改变一个接一个或所有。

OmniPlan提供了像甘特图，时间表，摘要，里程碑和关键路径的功能突出显示，让您管理您的所有活动。从自定义的视图来快速输入数据， OmniPlan帮助您管理，因为你需要他们，简单或复杂的项目是 – 不需要复杂。

 

以上软件都可以在微信公众号，回复“设计”，获取破解版本。

 

推荐阅读：

技术：HTTP状态码大全

技术：SpringBoot 如何在一分钟内整合SSM？

技术：CentOS7下Nginx服务器安装与使用教程

技术：Java9逆天的十大新特性

技术：http2.0的时代真的来了…

工具：如何通过技术手段 “干掉” 视频APP里讨厌的广告？

工具：通过技术手段 “干掉” 视频APP里讨厌的广告之（腾讯视频）

工具：抓包神器之Charles，常用功能都在这里了

干货分享：

分享：1T 软件开发视频资源分享

分享：深度机器学习56G视频资源分享

from:http://qkljs.iteye.com/blog/2412227

我要成为一个软件架构师。

对一个年轻的工程师来说，这是一个很好的目标。

我要领导一个团队，还要做所有关于数据库、框架和Web服务器的重要决定。

好吧，如果是这样，你就没必要成为一个软件架构师了。

当然有必要了！我要成为一个能够做所有重要决定的人。

这样很好，只是你没有列出哪些才是重要的决定。你刚才说的那些跟重要的决定没有什么关系。

你说什么？难道数据库不重要？你知道我们在数据库上面花了多少钱吗？

可能很多。不过数据库仍然不是最重要的。

你怎么能这么说呢？数据库可是整个系统的心脏啊！所有的数据都保存在这里，它们在这里被排序，被索引，被访问。如果没有数据库，整个系统就无法运作！

数据库只不过是一个IO设备，它提供了一些有用的工具对数据进行排序、查询，并生成报表，但这些工具都只是整个系统的附属品。

附属品？真是不可思议。

是的，附属品。你的系统业务逻辑或许会用到这些工具，但这些工具并非业务逻辑固有的组成部分。如果有必要，你可以随时替换掉这些工具，但业务逻辑还是那些业务逻辑。

好吧，不过如果把这些工具替换掉，我们就要重新实现业务逻辑了。

那是你的问题。

为什么这么说？

你认为业务逻辑依赖数据库，但实际上不是这样的。如果你的架构足够好，最起码业务逻辑不应该依赖数据库。

这太疯狂了。我怎么可能创建出不使用这些工具的业务逻辑？

我并没有说业务逻辑不要使用数据库工具，我的意思是它们不应该依赖这些工具。业务逻辑不应该知道使用的是哪一种数据库。

如果业务逻辑对数据库一无所知，它怎么使用这些工具呢？

依赖反转。你要让数据库依赖业务逻辑，而不是让业务逻辑依赖数据库。

你的话让人费解。

费解吗？我讲的可是软件架构。这个就是依赖反转原则，让下层策略来依赖上层策略。

那就更加费解了！既然上层策略（假设你指的是业务逻辑）要调用下层策略（假设你指的是数据库），那么就应该是上层策略依赖依赖下层策略，就像调用者依赖被调用者一样。这是众所周知的！

在运行时确实是这样的，但在编译时我们要把依赖反转过来。上层策略的代码里不要引用任何下层策略的代码。

拜托！不引用代码就无法调用它们。

当然可以调用了。面向对象就可以做到。

面向对象对真实世界进行建模，把数据和函数组合到对象里，把代码组织成直观的结构。

这是他们告诉你的吗？

所有人都知道的，这不是很明显的事情吗？

确实如此。不过，面向对象是可以做到不引用也能调用的。

好吧，那它是怎么做到的？

你应该知道，在面向对象系统里对象会给其它对象发送消息的，对吧？

是的，当然。

那么你就该知道，消息发送者是不知道消息接收者是什么类型的。

这要看使用的是哪一种语言了。在Java里，发送者最起码要知道接收者的基本类型。在Ruby里，发送者知道接收者一定会处理它所发送的消息。

是的。不过不管是哪一种情况，发送者都不知道接收者具体的类型。

嗯，是的。

所以发送者可以给接收者传递一个函数，让接收者执行这个函数，这样发送者就不需要知道接收者是什么类型了。

没错。我了解你的意思。不过发送者仍然依赖接收者。

在运行时确实是的，但在编译时不是这样的。发送者的代码里并没有引用接收者的代码。实际上，是接收者的代码依赖了发送者的代码。

啊！但发送者仍然会依赖接收者的类。

看来需要用代码来说明了，我用Java来写些代码。首先是发送者代码：

package sender;
public class Sender {
  private Receiver receiver;
  public Sender(Receiver r) {
    receiver = r;
  }
  public void doSomething() {
    receiver.receiveThis();
  }
  public interface Receiver {
    void receiveThis();
  }
}

下面是接收者代码：

package receiver;
import sender.Sender;
public class SpecificReceiver implements Sender.Receiver {
  public void receiveThis() {
    //这里会做一些有趣的事情
  }
}

可以看到，接收者代码依赖了发送者代码，也就是说SpecificReceiver依赖了Sender。同时可以看到，发送者代码对接收者代码一无所知。

哈，你作弊了。你把接收者的接口放到了发送者的类里了。

你开始明白了。

明白什么？

当然是架构原则啊。发送者持有接收者必须实现的接口。

如果这意味着我要使用内部类，那么……

使用内部类只是方法之一，还有其它的方法。

请等一下。最开始我们讨论的是数据库，那这些跟数据库又有什么关系呢？

让我们来看一下其它代码吧。首先是一个简单的业务逻辑

package businessRules;
import entities.Something;
public class BusinessRule {
  private BusinessRuleGateway gateway;
  public BusinessRule(BusinessRuleGateway gateway) {
    this.gateway = gateway;
  }
  public void execute(String id) {
    gateway.startTransaction();
    Something thing = gateway.getSomething(id);
    thing.makeChanges();
    gateway.saveSomething(thing);
    gateway.endTransaction();
  }
}

这个业务逻辑没有做什么事情啊。

这只是个例子。在实际实现业务逻辑的时候，不会有很多类似这样的类的。

好吧。那么Gateway是用来做什么的呢？

它为业务逻辑提供了所有访问数据的方法。下面是它的代码：

package businessRules;
import entities.Something;
public interface BusinessRuleGateway {
  Something getSomething(String id);
  void startTransaction();
  void saveSomething(Something thing);
  void endTransaction();
}

要注意，这个接口是在businessRules包里面的。

好吧。那Something这个类又是用来做什么的呢？

它代表一个简单的业务对象。我把它放在另一个叫entities的包里。

package entities;
public class Something {
  public void makeChanges() {
    //...
  }
}

最后需要实现BusinessRuleGateway接口，这个实现类会知道相关的数据库细节：

package database;
import businessRules.BusinessRuleGateway;
import entities.Something;
public class MySqlBusinessRuleGateway implements BusinessRuleGateway {
  public Something getSomething(String id) {
    // 从MySQL里读取一些数据
  }
  public void startTransaction() {
    // 开始一个事务
  }
  public void saveSomething(Something thing) {
    // 把数据保存到MySQL
  }
  public void endTransaction() {
    // 结束事务
  }
}

可以看到，业务逻辑是在运行时对数据库进行调用的。而在编译时，是database包引用了businessRules包。

好吧，我想我明白了。你用多态性隐藏了数据库实现。不过在业务逻辑里，仍然引用了数据库的工具接口。

不，不是这样的。我们并没有打算为业务逻辑提供所有的数据库工具接口，而是业务逻辑创建了它们所需要的接口。在实现这些接口的时候，可以调用相应的工具。

嗯，这样的话，如果业务逻辑需要所有的工具，那么你必须把所有工具都放到Gateway接口里。

哈，我觉得你还是没有明白。

不明白什么？我觉得已经很清楚了。

每个业务逻辑只定义它所需要的接口。

等等，什么意思？

这个叫作接口分离原则。每个业务逻辑只使用一部分数据库工具，所以每个业务逻辑只定义能够满足需要的接口。

这样的话，你就会有很多接口，而且有很多实现类。

哈，是的。你开始明白了。

这样子很浪费时间！我为什么要这样做呢？

这样做是为了让代码更干净，并且节省时间。

算了吧，这样只会增加更多的代码。

相反，这其实是很重要的架构决定，这跟你之前所说的那些所谓的重要决定是不一样的。

什么意思？

还记得你刚开始说你要成为一个软件架构师吗？你还想要做所有重要的决定？

是啊，我是这么想过。

你想做所有关于数据库、Web服务和框架的决定。

是啊，而你却说它们都不重要，还说它们其实跟重要的决定不相干。

没错，它们确实跟重要的决定不相干。一个软件架构师真正要做的重要决定都在数据库、Web服务器和框架之外。

但首先要先决定用什么数据库、Web服务器或框架啊！

不，实际上应该在开发后期才开始做这些事情——在你掌握了更多信息之后。
哀，当架构师草率地决定要使用一个数据库，后来却发现使用文件系统效率更高。
哀，当架构师草率的决定使用一个Web服务器，后来却发现团队需要的不过是一个socket借口。
哀，当架构师草率地决定使用一个框架，后来却发现框架提供的功能是团队不需要的，反而给团队带来了诸多约束。
幸，当架构师在掌握了足够多的信息后才决定该用什么数据库、Web服务器或框架。
幸，当架构师为团队鉴别出运行缓慢、耗费资源的IO设备和框架，这样他们就可以构建飞速运行的轻量级测试环境。
幸，当架构师把注意力放在那些真正重要的事情上，并把那些不重要的事情放在一边。

我完全不知道你在说什么了。

from:http://www.infoq.com/cn/news/2016/12/What-architect-do