什么是架构？一直以来也将自己定位为架构师（感觉还未真正入门T_T），但如果让自己能以最简洁的语言来描述它，有说说它具体的工作内容，还真的没有去认真思考过，只能大概的说个所以然。
架构一直在心里是一个很抽象的东西，就如下面描述的这样：
软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。
架构对于框架来说，它就是绘出好的建筑图纸，它描述建筑物的外部形状、内部布置、结构构造、内外装修、材料做法以及设备、施工等各种图样。
而在实际工作中，是怎么去做去执行的呢？在好长一段时间里我都无法将它明明白白的描述出来。只能说是凭经验，得到一个需求后就知道产品大概要怎么设计，它要用到那些技术，会大概面临什么问题，不同的问题或要求（性能、安全、数据量、并发......）在不同阶段要怎么去设计和用到那些技术，数据库结构要怎么去实现，是否需要分库分表，怎么设计才更有扩展性，怎么去解耦，编码时要用到多少人，这些人大概需要什么样的技能，需要多少开发时间，会不会出现延期，万一延期的话要怎么处理，测试呢？布署呢？版本更新迭代？每个阶段与其他相关部门的沟通？各种设计、开发、沟通文档？......
那具体怎么做呢？
这真不是三言两语就可以说得清楚的，去书店看着那一本本厚厚的架构设计书籍就知道了。因为针对不同的行业、不同规模的企业、公司技术环境、公司计划投入的资金大小、职位配备、项目的功能需求、技术人员能力、长短期目标、技术储备情况、使用的开发语言、数据库......都会影响架构师的判断，决定着当前（不是最终哦）使用的技术框架。当然在某些阶段也是有相同的地方，过程也大同小异，所以我们讨论架构的话，必须有个边界的限制。
首先，架构师必须了解具体的需求
不了解具体的业务需求，就没办法设计出一个成熟健壮的架构，也无法根据现实的具体环境，去选择出最适合当前公司或团队使用的技术架构，而导至各方面成本的增加，过度设计，投入大于产出；又或者产品扩展性不足无法应付业务增长及变化，而最终开发出来的产品也就很难吻合市场需求了。
客户、市场人员、老板、运营、销售、市场、架构、产品......不同的人员对产品都有不同的理解（比如餐饮行业中的：食客、收银、服务员、点菜、传菜、选菜、厨师、领班、店长、财务......对店里用的软件理解的角度也是不一样的），且同一个人在不同的场景针对不同的人说的同一句话都有可能意思都不一样，更何况这么多不同学历文化、职位、角色的人，大家对同样的话语、同样的描述的理解不同肯定也会产生不同的结果。
所以，架构师首先要做的，是自己去了解需求，然后将自己的理解通过使用各种工具将业务需求绘制出来，形成清晰、直观、容易了解的架构方案，和大家对称对项目需求理解，看看大家理解的信息是否一致，统一思想，防止偏差。
比如：使用UML绘制各种概念模型（用例图、泳道图、流程图、时序图......）；或是用DDD思想去创建各种领域、子域、限界上下文模型；又或者是用利益相关者的视角去绘制利益相关者视图、架构分层视图、业务产品视图、信息组织结构视图、业务功能视图、组织机构视图、业务流程视图、应用程序协作视图......
结束语：以上就是关于到底什么是架构的全部内容，更多内容请关注学步园。