很多人都想知道架构师是做什么？我们看看下面的一段对话。
菜鸟 —— 刚入门的程序员
老鸟 —— 资深架构师
老鸟：菜鸟，你的目标是什么？
菜鸟：我要成为一个软件架构师。
老鸟：对一个年轻的工程师来说，这是一个很好的目标。那你为什么要成为架构师呢？
菜鸟：我要领导一个团队，还要做所有关于数据库、框架和Web服务器的重要决定。
老鸟：好吧，如果是这样，你就没必要成为一个软件架构师了。
菜鸟：当然有必要了！我要成为一个能够做所有重要决定的人。
老鸟：这样很好，只是你没有列出哪些才是重要的决定。你刚才说的那些跟重要的决定没有什么关系。
菜鸟：你说什么？难道数据库不重要？你知道我们在数据库上面花了多少钱吗？
老鸟：可能很多。不过数据库仍然不是最重要的。
菜鸟：你怎么能这么说呢？数据库可是整个系统的心脏啊！所有的资料都储存在这里，它们在这里被排序，被索引，被访问。如果没有数据库，整个系统就无法运作！
老鸟：数据库只不过是一个IO装置，它提供了一些有用的工具对资料进行排序、查询，并生成报表，但这些工具都只是整个系统的附属品。
菜鸟：附属品？真是不可思议。
老鸟：是的，附属品。你的系统业务逻辑或许会用到这些工具，但这些工具并非业务逻辑固有的组成部分。如果有必要，你可以随时替换掉这些工具，但业务逻辑还是那些业务逻辑。
菜鸟：好吧，不过如果把这些工具替换掉，我们就要重新实现业务逻辑了。
老鸟：那是你的问题。
菜鸟：为什么这么说？
老鸟：你认为业务逻辑依赖数据库，但实际上不是这样的。如果你的架构足够好，最起码业务逻辑不应该依赖数据库。
菜鸟：这太疯狂了。我怎么可能创建出不使用这些工具的业务逻辑？
老鸟：我并没有说业务逻辑不要使用数据库工具，我的意思是它们不应该依赖这些工具。业务逻辑不应该知道使用的是哪一种数据库。
菜鸟：如果业务逻辑对数据库一无所知，它怎么使用这些工具呢？
老鸟：依赖反转。你要让数据库依赖业务逻辑，而不是让业务逻辑依赖数据库。
菜鸟：你的话让人费解。
老鸟：费解吗？我讲的可是软件架构。这个就是依赖反转原则，让下层策略来依赖上层策略。
菜鸟：那就更加费解了！既然上层策略（假设你指的是业务逻辑）要呼叫下层策略（假设你指的是数据库），那么就应该是上层策略依赖依赖下层策略，就像呼叫者依赖被呼叫者一样。这是众所周知的！
老鸟：在执行时确实是这样的，但在编译时我们要把依赖反转过来。上层策略的程式码里不要引用任何下层策略的程式码。
菜鸟：拜托！不引用程式码就无法呼叫它们。
老鸟：当然可以呼叫了。面向物件就可以做到。
菜鸟：面向物件对真实世界进行建模，把资料和函式组合到物件里，把程式码组织成直观的结构。
老鸟：这是他们告诉你的吗？
菜鸟：所有人都知道的，这不是很明显的事情吗？
老鸟：确实如此。不过，面向物件是可以做到不引用也能呼叫的。
菜鸟：好吧，那它是怎么做到的？
老鸟：你应该知道，在面向物件系统里物件会给其它物件传送讯息的，对吧？
菜鸟：是的，当然。
老鸟：那么你就该知道，讯息传送者是不知道讯息接收者是什么型别的。
菜鸟：这要看使用的是哪一种语言了。在Java里，传送者最起码要知道接收者的基本型别。在Ruby里，传送者知道接收者一定会处理它所传送的讯息。
老鸟：是的。不过不管是哪一种情况，传送者都不知道接收者具体的型别。
菜鸟：嗯，是的。
老鸟：所以传送者可以给接收者传递一个函式，让接收者执行这个函式，这样传送者就不需要知道接收者是什么型别了。
菜鸟：没错。我了解你的意思。不过传送者仍然依赖接收者。
老鸟：在执行时确实是的，但在编译时不是这样的。传送者的程式码里并没有引用接收者的程式码。实际上，是接收者的程式码依赖了传送者的程式码。
菜鸟：啊！但传送者仍然会依赖接收者的类。
老鸟：看来需要用程式码来说明了，我用Java来写些程式码。首先是传送者程式码：
老鸟：下面是接收者程式码：
老鸟：可以看到，接收者程式码依赖了传送者程式码，也就是说SpecificReceiver依赖了Sender。同时可以看到，传送者程式码对接收者程式码一无所知。
菜鸟：哈，你作弊了。你把接收者的界面放到了传送者的类里了。
老鸟：你开始明白了。
菜鸟：明白什么？
老鸟：当然是架构原则啊。传送者持有接收者必须实现的界面。
菜鸟：如果这意味着我要使用内部类，那么……
老鸟：使用内部类只是方法之一，还有其它的方法。
菜鸟：请等一下。最开始我们讨论的是数据库，那这些跟数据库又有什么关系呢？
老鸟：让我们来看一下其它程式码吧。首先是一个简单的业务逻辑
菜鸟：这个业务逻辑没有做什么事情啊。
老鸟：这只是个例子。在实际实现业务逻辑的时候，不会有很多类似这样的类的。
菜鸟：好吧。那么Gateway是用来做什么的呢？
老鸟：它为业务逻辑提供了所有访问资料的方法。下面是它的程式码：
老鸟：要注意，这个界面是在businessRules包里面的。
菜鸟：好吧。那Something这个类又是用来做什么的呢？
老鸟：它代表一个简单的业务物件。我把它放在另一个叫entities的包里。
老鸟：最后需要实现BusinessRuleGateway界面，这个实现类会知道相关的数据库细节：
老鸟：可以看到，业务逻辑是在执行时对数据库进行呼叫的。而在编译时，是database包引用了businessRules包。
菜鸟：好吧，我想我明白了。你用多型性隐藏了数据库实现。不过在业务逻辑里，仍然引用了数据库的工具界面。
老鸟：不，不是这样的。我们并没有打算为业务逻辑提供所有的数据库工具界面，而是业务逻辑建立了它们所需要的界面。在实现这些界面的时候，可以呼叫相应的工具。
菜鸟：嗯，这样的话，如果业务逻辑需要所有的工具，那么你必须把所有工具都放到Gateway接口里。
老鸟：哈，我觉得你还是没有明白。
菜鸟：不明白什么？我觉得已经很清楚了。
老鸟：每个业务逻辑只定义它所需要的界面。
菜鸟：等等，什么意思？
老鸟：这个叫作界面分离原则。每个业务逻辑只使用一部分数据库工具，所以每个业务逻辑只定义能够满足需要的界面。
菜鸟：这样的话，你就会有很多界面，而且有很多实现类。
老鸟：哈，是的。你开始明白了。
菜鸟：这样子很浪费时间！我为什么要这样做呢？
老鸟：这样做是为了让程式码更干净，并且节省时间。
菜鸟：算了吧，这样只会增加更多的程式码。
老鸟：相反，这其实是很重要的架构决定，这跟你之前所说的那些所谓的重要决定是不一样的。
菜鸟：什么意思？
老鸟：还记得你刚开始说你要成为一个软件架构师吗？你还想要做所有重要的决定？
菜鸟：是啊，我是这么想过。
老鸟：你想做所有关于数据库、Web服务和框架的决定。
菜鸟：是啊，而你却说它们都不重要，还说它们其实跟重要的决定不相干。
老鸟：没错，它们确实跟重要的决定不相干。一个软件架构师真正要做的重要决定都在数据库、Web服务器和框架之外。
菜鸟：但首先要先决定用什么数据库、Web服务器或框架啊！
老鸟：实际上应该在开发后期才开始做这些事情——在你掌握了更多资讯之后。
老鸟：当架构师草率地决定要使用一个数据库，后来却发现使用档案系统效率更高。
老鸟：当架构师草率的决定使用一个Web服务器，后来却发现团队需要的不过是一个socket界面。
老鸟：当架构师草率地决定使用一个框架，后来却发现框架提供的功能是团队不需要的，反而给团队带来了诸多约束。
老鸟：当架构师在掌握了足够多的资讯后才决定该用什么数据库、Web服务器或框架。
老鸟：当架构师为团队鉴别出执行缓慢、耗费资源的IO装置和框架，这样他们就可以构建飞速执行的轻量级测试环境。
老鸟：当架构师把注意力放在那些真正重要的事情上，并把那些不重要的事情放在一边。
菜鸟：我完全不知道你在说什么了。
老鸟：好吧，如果在若干年后你还没有转做管理，或许会明白这一切的……
对话来源网络，若有侵权，请联络删除
通过上面的对话，让我们对架构师有了个简单的了解，那么架构师在一家公司有多重要呢？架构师对一家公司、一个专案有多重要？
我们来看一看调查的资料
架构师在公司中担当着“IT架构灵魂人物”的角色，因为他们不仅做着架构师的本职工作，还同时做程式开发，写核心程式码。另外，架构师依旧是技术高手，程式设计能力依然是一流的。
从图表结果来看，架构师必须具备出色的设计能力、程式设计能力和沟通能力，在完成本职的架构工作外，还要协调好专案中人员的关系，做出合理的分工，最终完成全部工作。
最后，看下企业对Java架构师的职位描述与职位要求
从招聘资讯来看，架构师们必须是具有多年的从业经验，有过专案开发经历，精通多门程式语言且熟悉数据库的大咖。所以，想以架构师为目标的读者，就要加倍努力了！
