现代API(通往架构师之门)

作者简介

内容简介

第1章概述 在软件行业里,架构师们的头上仿佛都带有光环。他们往往对复杂的问题举重若轻。几乎每一个年轻的程序员都希望有朝一日自己也能成为一名经验丰富的架构师,领导着一个开发团队、解决着世界上最复杂的软件架构设计和实施的问题。 然而,一名成功的架构师到底学习了哪些东西、又经历了怎样的历练，似乎没有人讲解过；大学里从来不曾开设过相应的课程,更没有人能够提供一张“课程表”；市面上的关于架构的图书大多或偏重于讲授抽象的设计原则，或偏重于对设计思想的感悟。读者如果没有亲身经历过具体的项目案例，抽象的设计原则缺乏系统的应用指导和可执行性，而感悟只有在读者亲自做过之后才有可能产生共鸣。那些缺乏经验的新人该怎么办呢？他们是多么希望有一张通向架构师的路线图啊！ 1.1什么是架构和架构师 万事开头难,文章开篇难！为了建立一个大家理解相同、不产生歧义的沟通基础，我们必须从两个最基本的概念入手。 首先，最重要的概念就是架构。按照维基百科的说法https：//en.wikipedia.org/wiki/Software_architecture： 软件架构是指软件系统在高层次上的结构、创建此类结构的指导原则，以及这些结构的相关文档。这些结构可以用来推断和评价待建的软件系统。每一个结构包含软件的组成部分及其相互之间的关系，以及组成部分和相互关系的属性。一个软件系统的架构类似于建筑的架构。其次，就是架构师的概念及分类。还是按照维基百科的说法https：//en.wikipedia.org/wiki/Software_architect： 软件架构师的工作就是进行高层次上的设计方案选择、制定相关的技术标准，包括软件编码标准，并确定所使用的软件工具和平台。尽管有人将架构师的种类分得很细https：//blog.prabasiva.com/2008/08/21/differenttypesofarchitects/，实际最常见的架构师分为两种。〖=1〗 企业架构师（Enterprise Architect）： 研究的对象是解决方案架构师在实施工作过程中所使用的方法，为后者解决具体的业务问题提供架构设计以及实施的具体步骤和方法指导。  解决方案架构师（Solution Architect）： 实际承担解决企业业务问题的任务。有可能需要使用企业架构师所提供的架构设计以及实施的具体步骤和方法指导。〖=2〗换句话说，企业架构师解决的是IT问题，而解决方案架构师解决的是业务问题。贯穿本书所指的架构师是后一种，即解决方案架构师。不仅如此，本书面向的是那些解决方案涉及多个功能系统的使用、架构原则和思想具有横跨企业的指导意义的架构师。 1.2这本书是为谁写的 本书针对的读者群包括希望成为解决方案架构师的程序员、IT咨询师，希望通过与同行进行交流而得到提高的架构师，还有希望了解如何能够让自己的部门有效地应对不断变化的企业业务要求的各级IT 领导。 一名IT从业人员可能正处在下面列出的一种情形之中： 1) 刚刚走出大学的校门、参加工作。在计算机系里已经学会了一门或几门编程语言（如Java、C#、Python，等等），以及数据结构和算法，对后台数据库、网站架构甚至SOAP Webservices都有初步的了解，并且可以很熟练地进行编程来解决别人交给的非常具体的问题。但是如果面对类似本章1.3节中所描述的那几个实战例子就不知从何下手了。 2) 从事软件开发工作3～5年，十分胜任小型或局部问题的分析、方案设计和具体实施。然而面对规模稍大、更加复杂并涉及多个系统的业务问题的设计任务时会感到力不从心，不知道从何下手，不知道应该采用什么样的原则以及设计和实施步骤，也不知道应该使用何种工具。 3) 作为一名具有2～3年实际经验的架构师，已经参与和主持了几个系统集成项目的设计和实施工作，但对为什么采用某个设计方案、其优点和缺点的评估却说不出个所以然来，因此无法在下一个项目的工作中信心十足地再次采用类似的方案。 4) 从事架构师的工作已有5～10年，能够深入了解具体设计方案背后的来龙去脉，以及设计方案的优点、缺点甚至相应的补救措施。然而，面对一个复杂项目各方面的利益相关人（如项目出资方、业务分析人员、其他设计人员、开发团队、项目经理、合作伙伴，等等），深深地感到将项目设计的思想和方案优缺点论述清楚并得到方方面面的支持是一件十分困难的事情。即便是开发团队内部的技术细节的沟通和统一也不是那么容易。 "汇集20年系统集成和API项目实战经验，软件开发人员成为架构师的必读指南 "