早上醒来打开手机，浏览完该看的信息后，随意点看某脉求职，由于自己定制的都是架构和开发类别，所以看到的招聘几乎都是架构师职位，薪酬几乎都在30~50K/月，好是羡慕（几乎都是招Java架构的......看来还是得加快学习进度，转型速度要快点）。心想如果自己去面试这些职位时，对方万一问：“你来应聘架构师，那你来说说什么是架构？”时，自己要怎么回答？从而引起来下面的联想，哈哈......随想嘛，所以本篇只讨论操作步骤，不谈具体的实现细节，将一时的想法记录一下
什么是架构？一直以来也将自己定位为架构师（感觉还未真正入门 T_T ），但如果让自己能以最简洁的语言来描述它，有说说它具体的工作内容，还真的没有去认真思考过，只能大概的说个所以然。
架构一直在心里是一个很抽象的东西，就如下面描述的这样：
软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。
架构对于框架来说，它就是绘出好的建筑图纸，它描述建筑物的外部形状、内部布置、结构构造、内外装修、材料做法以及设备、施工等各种图样。
而在实际工作中，是怎么去做去执行的呢？在好长一段时间里我都无法将它明明白白的描述出来。只能说是凭经验，得到一个需求后就知道产品大概要怎么设计，它要用到那些技术，会大概面临什么问题，不同的问题或要求（性能、安全、数据量、并发......）在不同阶段要怎么去设计和用到那些技术，数据库结构要怎么去实现，是否需要分库分表，怎么设计才更有扩展性，怎么去解耦，编码时要用到多少人，这些人大概需要什么样的技能，需要多少开发时间，会不会出现延期，万一延期的话要怎么处理，测试呢？布署呢？版本更新迭代？每个阶段与其他相关部门的沟通？各种设计、开发、沟通文档？......
那具体怎么做呢？
这真不是三言两语就可以说得清楚的，去书店看着那一本本厚厚的架构设计书籍就知道了。因为针对不同的行业、不同规模的企业、公司技术环境、公司计划投入的资金大小、职位配备、项目的功能需求、技术人员能力、长短期目标、技术储备情况、使用的开发语言、数据库......都会影响架构师的判断，决定着当前（不是最终哦）使用的技术框架。当然在某些阶段也是有相同的地方，过程也大同小异，所以我们讨论架构的话，必须有个边界的限制。
首先，架构师必须了解具体的需求
不了解具体的业务需求，就没办法设计出一个成熟健壮的架构，也无法根据现实的具体环境，去选择出最适合当前公司或团队使用的技术架构，而导至各方面成本的增加，过度设计，投入大于产出；又或者产品扩展性不足无法应付业务增长及变化，而最终开发出来的产品也就很难吻合市场需求了。
客户、市场人员、老板、运营、销售、市场、架构、产品......不同的人员对产品都有不同的理解（比如餐饮行业中的：食客、收银、服务员、点菜、传菜、选菜、厨师、领班、店长、财务......对店里用的软件理解的角度也是不一样的），且同一个人在不同的场景针对不同的人说的同一句话都有可能意思都不一样，更何况这么多不同学历文化、职位、角色的人，大家对同样的话语、同样的描述的理解不同肯定也会产生不同的结果。
所以，架构师首先要做的，是自己去了解需求，然后将自己的理解通过使用各种工具将业务需求绘制出来，形成清晰、直观、容易了解的架构方案，和大家对称对项目需求理解，看看大家理解的信息是否一致，统一思想，防止偏差。
比如：使用UML绘制各种概念模型（用例图、泳道图、流程图、时序图......）；或是用DDD思想去创建各种领域、子域、限界上下文模型；又或者是用利益相关者的视角去绘制利益相关者视图、架构分层视图、业务产品视图、信息组织结构视图、业务功能视图、组织机构视图、业务流程视图、应用程序协作视图......
其次，设计产品，细化各种模型与视图
当大家对产品的理解统一之后，开始由产品经理来设计产品原型，以及架构师对前面模型与视图进行细化，形成一份份与技术相关的各种文档，指导后续工作的开展。
产品原型与各模型是相辅相成的，产品原型是模型的可视化体现，而模型是产品后端复杂的业务实现。
成熟的架构师除了懂得针对需求建立各种模型外，还要懂得从需求与产品中，提炼出成熟的商业模式与盈利模式，一个软件如果不存在行业价值或商业价值，最终实现盈利，那它也走不了多远。
然后，根据所在行业、公司、部门等各种综合情况，再确定使用具体的技术框架
每个行业都有自己的特殊性，在这里就不进行深入讨论了。
而每个公司的资金实力都是不一样的，技术部分的岗位职位配置也各不相同，使用的技术语言也是各种各样，再加上技术人员技能水平也是高低有别，所以一套架构可以通吃的情况是不存在的。
资金充沛的土豪公司可以随意，缺什么职位就随便高薪聘请，而用的技术框架也可以直接上高大上的那些组合，不用去考虑开发时间与成本......呵呵，这些对于绝大部分公司来说YY就好了，我们还是要回到现实中来，我们经常会碰到的是资金有限，人手不足，公司使用指定的技术或框架......然后对投入与时间又有严格要求，但又想系统开发出来以后系统可以随时扩展，应付万一业务做大，高并发、大数据、分布式、可扩展......等都要能对接的上且不用花费太大的成本，呃......
好的架构会对业务发展和技术发展做好提前预判（虽然不一定一直都正确），提前采用适合的性能比最好的技术架构来实现。当然在发展的过程中，如果真的公司业务量起来了，改造也大都在合理的范围内。在不可避免需要进行大改造时，那也是有选择有计划的替换某些模块。
再具体点来说，就是要使用.net、java、php、pyton还是什么开发语言，使用SOA架构、微服务架构，还是传统的软件架构，软件框架用MVC、传统三层、DDD......数据层用EF、MyBatis、Hibernate......其他层呢？使用分布式架构还是一体式？使用消息阵列吗？总线呢？前端框架呢？要考虑客户端兼容什么版本手机或浏览器？安全呢？工作流？数据结构设计？开发模式是TDD/DDD/PDD/敏捷？人员分工安排？开发计划？开发进度控制？......
跟着才进入具体的开发实现
这部分大家是最熟悉的就不扩展了
最后是测试、部署，产品的迭代
......
当然，并不是所有项目都是按这个顺序来执行的，小项目小需求无架构，对于简单的需求开发一个简单功能的产品，直接画个草图然后码代码就可以了，考虑太多反而是过度设计浪费时间。当然架构师也不是万能的什么都懂什么都会，一个人无法完成一个大中型项目的开发，它需要团队中各个成员的密切配合，一起努力完成。
可以说每个架构师心中都有片森林，清晰的知道设定好目标以后，为了完成这个目标，我们会提前做好全方位的计划，当然这个计划不只是技术上的，还会关系到相关部门的沟通与配合，清楚在前进的路途中每一个节点或阶段性目标要达到时需要的准备工作与各部门提供的配合工作。然后就是把控好这个节奏，让产品的大船沿着正确的方向前进，最终到达目的地。
完美的架构师，他是技术总监、系统分析师、架构师、产品经理、项目经理、核心开发、测试人员，他是堵枪眼的角色，那个岗位需要随时准备顶上的人员。
知识有限对架构师的认识比较浅簿，想到哪就写到哪，不知这样认为是否正确，欢迎大家指正。
版权声明：
本文由AllEmpty原创并发布于博客园，欢迎转载，未经本人同意必须保留此段声明，且在文章页面明显位置给出原文链接，否则保留追究法律责任的权利。如有问题，可以通过1654937@qq.com 联系我，非常感谢。
发表本编内容，主要是为了和大家共同学习共同进步，有兴趣的朋友可以加加Q群：327360708 ，大家一起探讨，我们群每半个月会组织一次在群视频里进行技术分享，有兴趣的朋友可以加入进来一起探讨。
更多内容，敬请观注博客：http://www.cnblogs.com/EmptyFS/