关键词：
简介
每一个程序员心中都有个架构师的梦想，架构是如此的重要，以至于每个程序员都在谈架构，仿佛没有架构的软件是没有灵魂的，不想做架构师的程序员不是一个好的码农一样。
那么架构到底是什么呢？架构是怎么得到的呢？今天本文将会从自身的经验来阐述一下对架构的看法。
什么是架构
在软件发展的初期是没有架构而言的。从最早的汇编语言到过程语言，他们处理的是一个个任务，为此编制了一个个的函数来执行对应的任务。这时候的软件编程语言还是过程语言，所以谈不上架构。
随着硬件技术的成熟，能够处理的任务越来越多，为了处理这么多的任务，编程语言也从面向过程转变为面向对象，从而更好的适应任务的发展。软件越来复杂，要处理的任务越来越多，最终导致了系统架构的产生。
架构是在复杂软件结构中产生的，它的任务就是让这些复杂软件中的任务能够互相协作从而来完成共同的任务。当然这是从软件的目标来说的。如果再考虑软件的实现和扩展性，那么好的架构需要让系统可读性和可扩展性更强，给未来留出一定的空间。如果从可靠性和可用性来讲，好的架构还需要保证系统高可用和容错性。
我们要注意的是，架构并不是空想而来的，它的基石在于编写的程序。所以架构需要跟程序紧密结合才能产生活力。
系统的架构主要描述的是系统的主要组件和这些组件之间的关系和他们如何进行交互。
架构的关键设计原则
为了最大程度的降低成本，满足功能需求，并最大程度的提高系统结构的可扩展性和可用性，我们需要考虑下面几个关键的设计原则：
- 关注点分离原则
将系统的组件按照特定的功能进行划分，从而是组件的功能之间没有重复。从而保证高内聚力和低耦合度。这种方法避免了系统组件之间的相互依赖性，有助于简化系统。
- 单一责任原则
系统的每个模块都应负一个特定的责任，这有助于用户清楚地了解系统。它还有助于组件与其他组件的集成。
- 最少知识原理
任何组件或对象都不应该获取其他组件的内部细节。这种方法避免了相互依赖，并提高可维护性。
- 最大限度地减少前期的大型设计
如果应用程序的需求不清楚，则最大程度地减少前期的大型设计。从小的原型出发，在探索中确认好需求。避免后期因为需求变动导致的巨大重构工作量。
- 不要重复功能
“不重复功能”指的是不要重复组件的功能，一个逻辑的实现，只应该存在于一段代码中。如果有多处代码的拷贝，那么在逻辑发生变化的时候，功能的重复会使其难以实施更改，降低清晰度并引入潜在的不一致之处。
- 重用功能时要优先考虑组合而不是继承
继承会在子类和父类之间建立依赖关系，因此会阻止子类的自由使用。相反，组合提供了很大的自由度并减少了继承层次结构。
- 定义不同层之间的通信协议
要对部署方案和生产环境有完整的了解，从而制定出或者使用合适的通信协议。
- 定义组件之间交互的数据格式
各种组件将通过数据格式相互交互。最好统一数据格式，从而使应用程序易于实现，扩展和维护。通过使用相同的数据格式，以便各个组件在相互通信时无需对数据进行编码/解码。它减少了处理开销。
- 系统服务组件应该是抽象的
与安全性，通信或系统服务（例如日志记录，概要文件和配置）相关的代码应在单独的组件中抽象出来。请勿将此代码与业务逻辑混合使用，这样扩展设计和维护将会变得容易。
- 设计异常和异常处理机制
预先定义异常，有助于组件以优雅的方式管理错误或意外情况。最好在整个系统中使用相同的异常处理机制。
- 命名约定
命名约定应事先定义。它们提供了一个一致的模型，可以帮助用户轻松理解系统。团队成员更容易验证其他人编写的代码，因此会增加可维护性。
架构的描述
既然架构这么重要，我们可以使用什么样的手段才能够描述架构中的组件、组件之间的联系和他们的交互呢？业界也探讨了很多方法。这里我们也来介绍几种方法。
UML
UML大家应该都很熟悉了，它的全称是统一建模语言，它是一种图形语言。UML1.0规范是在1997年1月由对象管理组（OMG）提出的。它用作软件需求分析和设计文档的标准，这些文档是开发软件的基础。
UML是可视化的建模语言，里面包含很多组件，这些组件通过不同的方式关联，从而形成了完整的UML图。尽管通常使用UML对软件系统进行建模，但它并不局限于此范围。UML也被用于建模非软件系统，例如制造单元中的流程。
UML主要分成两大类别：结构图和行为图。
结构图表示系统的静态组件。 这些静态组件由类，接口，对象，组件和节点表示。结构图包含下面几个部分：
- 类图： 表示面向对象系统中的各个类和他们间的关系。
- 对象图：对象图表示的是运行时的对象和他们的关系。
- 组件图：组件图描述的是系统中的所有组件、接口和他们的交互关系。
- 复合结构：描述组件的内部结构，包括所有类，组件的接口等。
- 包：包主要是包含类和其他的包。
- 部署图：部署图是一组节点及其关系。 这些节点是部署组件的物理实体。
行为图表示的是系统中可能出现的动作，行为图可以包含下面几种：
- 用例图：描述功能及其内部/外部控制器之间的关系。 这些控制器被称为参与者。
- 活动图：描述系统中的控制流。 它由活动和链接组成。 该流可以是顺序的，并发的或分支的。
- 状态图：表示系统的事件驱动状态更改。 它描述了类，接口等的状态变化。
- 序列图：可视化系统中执行特定功能的顺序。
- 组合活动图和序列图以提供系统和业务流程的控制流概述。
架构视图
视图是从一组相关关注点的角度对整个系统的表示。它用于从不同的利益相关者（例如最终用户，开发人员，项目经理和测试人员）的角度描述系统。这里给大家介绍一个叫做4 + 1的视图模式。
4 + 1视图模型是由Philippe Kruchten发明的。该模型基于对多个视图和并发视图的使用来描述软件密集型系统的体系结构。它是一个多视图模型，解决了系统的不同功能和关注点。它使软件设计文档标准化，并使所有利益相关者易于理解设计。
它包含了4个基本的视图，分别是：
1. 逻辑视图或概念视图-它描述了设计的对象模型。
2. 流程视图-描述了系统的活动，包括并发和同步。
3. 物理视图-它描述了软件到硬件的映射并反映了其分布式关系。
4. 开发视图-它描述了环境开发中软件的静态组织和结构。
最后的+1视图表示的是为最终用户或客户添加一个称为方案视图或用例视图的视图。它和其他的4个视图是一致的，所以被称为+1 视图。
ADL
架构描述语言ADL是一种语言，提供用于定义软件体系结构的语法和语义。它是一种注释规范，提供了用于对软件系统的概念体系结构进行建模的功能，这与系统的实现有所不同。
架构描述语言是一种形式化的规范语言，它描述诸如进程，线程，数据和子程序之类的软件功能，以及诸如处理器，设备，总线和内存之类的硬件组件。
总结
今天的架构漫谈就讲到这里，有不住之处还希望大家多多指正。后续会给大家介绍几种常见的架构模式。希望大家能够喜欢。
本文已收录于 http://www.flydean.com/06-software-architecture/
最通俗的解读，最深刻的干货，最简洁的教程，众多你不知道的小技巧等你来发现！
欢迎关注我的公众号:「程序那些事」,懂技术，更懂你！
《架构漫谈》读后感之“关于软件架构师如何工作”
通过社会的架构举例，从原始自给自足独立完成衣食住行，到发展中分工合作、相互沟通、将事物完成到一个更好的水平。从而我知道了架构的动力：必须由人执行的工作每个人的能力有限每个人的时间有限人对目标系统有... 查看详情
软件架构师如何工作-架构漫谈阅读笔记
在王概凯先生的9篇关于软件架构师的博客-《架构漫谈》中，我们可以看到文中谈到了架构的定义、含义，架构主要是要认识概念，如何做好架构之架构的切分，然后谈到了软件与架构之间的关系（什么是软件，软件架构是... 查看详情
《架构漫谈》之阅读笔记
什么是架构？在维基百科上是这样定义的：架构是一种过程，并且是计划、设计、构建和其他物理结构的产品。在《架构漫谈》一中认为，架构就是根据要解决的问题，对目标系统的边界进行界定。并对目标系统按某个原则... 查看详情
架构漫谈：如何做好架构之架构切分
本文是漫谈架构专栏的第四篇，作者将会介绍架构的切分，并直戳切分的本质其实就是利益的调整。文中作者将会讨论为什么需要切分、切分的原则、切分与建模、切分的输出和组织架构等问题。欢迎阅读和反馈。前一... 查看详情
阅读《架构漫谈》后，思考软件架构师应该如何工作
老师上课围绕《架构漫谈》前四篇图文并茂的讲解了何为架构，架构的基础，以及识别问题和架构切分这些作为架构师需要了解的最基本的知识。现在要讨论的是软件架构师应该如何工作，如何更好的，更快的，更有效率的... 查看详情
架构漫谈之感想
...为一个整体，并完成这个整体所需要的所有活动，这就是架构。架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，解决这个问题的实践活动。 &nbs 查看详情
架构漫谈：如何做好架构之识别问题
按照之前架构的定义，做好架构首先需要做的就是识别出需要解决的问题。一般来说，如果把真正的问题找到，那么问题就已经解决了80%了。这个能力基本上就决定了架构师的水平。 那么面对问题有哪些困难呢?我们先看一... 查看详情
阅读架构漫谈九篇博客有感-1500字
架构漫谈是由资深架构师王概凯撰写的系列专栏，逐步讨论什么是架构、怎样做好架构、软件架构如何落地、如何写好程序等问题。架构漫谈分为九篇：什么是架构？认识概念是理解架构的基础如何做好架构之识别问题如何做好... 查看详情
架构漫谈：什么是软件
本文是漫谈架构专栏的第五篇，作者将会从自己的认知角度再次反思什么是软件，文中作者探讨了软件发展火热的根本原因以及软件扮演的角色等问题。如前几天一位架构师所说，我们并不缺架构实践，而是缺少... 查看详情
架构漫谈：如何做好架构之识别问题
笑谈按照之前架构的定义，做好架构首先需要做的就是识别出需要解决的问题。一般来说，如果把真正的问题找到，那么问题就已经解决了80%了。这个能力基本上就决定了架构师的水平。那么面对问题有哪些困难呢?... 查看详情
《架构漫谈》阅读笔记
架构漫谈是由资深架构师王概凯执笔的系列专栏，通过对其阅读，我从中逐步认识到了什么是架构，怎样做好架构，软件架构如何落地等内容。 一、什么是架构 在软件行业，对于什么是架构一直有很多的争论。事实... 查看详情
架构漫谈阅读笔记
原来通过阅读《大型网站架构》的阅读，对架构的原则和特点有了了解，但对于为什么要进行架构以及如何真正实现架构还并没有真正的了解。这几天我通通过阅读由资深架构师王概凯执笔的系列专栏——架构漫谈，让... 查看详情
《漫谈架构》读后感——软件架构师如何工作
看了漫谈架构，首先理解了什么是架构和为什么会产生架构。架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，解决这个问题的实践活动。架构实际上解决的是... 查看详情
《架构漫谈》阅读笔记
软件架构师如何工作？ 不同于软件工程中只需要编码的“低级”码农，一名合格的软件架构师首先要对架构有深刻的理解。那么什么是架构？从建筑的角度解释，架构是计划、设计和建造建筑物、物理结构的过程和生产... 查看详情
《架构漫谈》读后感
要学好软件架构，首先要解决的问题就是什么是架构。一直以来，在软件行业，对于架构的定义都有争议，很多人都在讨论架构，但是很多人都不知道到底什么是架构。很多大佬都对这个架构... 查看详情
《架构漫谈》读后感
软件架构师，乍一听给人很高大上的感觉，技术型工程师，站在金字塔顶端的角色，看完九篇博客之前，在网上搜了搜软件架构师的词条。 什么是软件架构师 软件架构师是软件行业中一种新兴职业，是软件项目的总... 查看详情
架构漫谈阅读笔记
《架构漫谈》读后感 经过一个寒假对《架构之美》的解读，其实我已经对什么是架构有了一个初步的认识，但是还是有一些不太明白的地方。今天，我仔细地阅读了由资深架构师王概凯Kevin执笔的系列专栏——... 查看详情
读《架构漫谈》的一些感想
在阅读王概凯的《架构漫谈》，一共9篇。读之前以为的架构：架构啊，应该就是像想要盖房子一样，用木头搭起来的一个框架吧。听这名字，架构架构，多像“构造的架子”。读之后：我是谁？我在哪？架构能吃吗？... 查看详情