语言做一个自动售货机软件_【转】对软件架构的一些思维脑图整理 - 立志做一个好的程序员...

原文： https://blog.csdn.net/enweitech/article/details/80505082

-------------------------------

软件架构(software architecture)就是软件的基本结构。

合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位(architect)，只有资深程序员(现在流行全栈工程师和Devops架构师)才可以担任。

百科释义：架构

架构可细分为业务架构、应用架构和技术架构。业务架构是战略，应用架构是战术，技术架构是装备。

首先讲的是“业务架构,功能架构,系统架构,技术架构，应用架构”里面是有重叠的，其中功能架构 可以是业务架构部分、也可以是应用架构部分，系统架构和技术架构是重叠的，可以把这两个名称叫一个名称就行。我的个人理解是：

 业务(逻辑)架构：使用一套方法论对产品(项目)所涉及到的需求的业务进行业务边界划分，简单的讲就是根据一套逻辑思路进行业务的拆分，总体原则是对业务进行业务边界的划分，比如做一个企业订购服务网站，你需要把商品类目、商品、订单、订单服务、支付、退款很清晰的划分出来，而业务架构不需要考虑诸如我用什么技术开发、我的并发大怎么办、我选择什么样的硬件等等。 

应用架构：应用是介于业务语言与技术语言之间，是对整个系统实现的总体上的架构，他需要指出系统的层次、系统开发的原则、系统各个层次的应用服务，例如，上述系统中可以分为、数据层(资源层)、数据服务层、中间构建服务层、业务逻辑层、表现层，并写明每个层次应用服务。 

数据(持久化)架构：对存储数据(资源)的架构方法论，其架构原则同应用架构大同小异，即考虑到各个系统应用场景、不同时间段的应用场景对数据进行诸如数据异构、读写分离、数据库或NOSQL的策略、缓存的使用、分布式数据(数据库)策略等等。 

技术架构：我的理解是对上述架构中提出的功能(或服务)进行技术方案的实现。包括软件系统实现、操作系统选择、运行时设计。技术架构设计面较广，专业性较强。

简单来说，这些架构面向的人群不同。 
业务架构、功能架构面向业务人员，业务用来告诉业务人员我们要做的系统或系统群为哪些业务提供了系统支撑，功能架构用于描述细分业务下提供了哪些功能，注意这里的功能和技术人员的功能的定义是有偏差的。 应用架构是介于技术和业务之间的一个管理层面的中间产物，简单点讲某个业务的功能可能分布在不同的应用中，某个应用可能由多个系统协作来完成。一般企业以应用为管理单元。 系统架构用于描述系统定位与集成关系，是用来圈定单个系统的功能范围的。关注系统架构的一般是科技条线的中层，通常会按照系统架构制定项目计划。 技术架构的边界比较模糊，对不同受众描述的详细程度不同，科技条线自上而下都是比较关注技术架构的，但是各层关注的点不同，高层可能关心的是对系统或系统群使用的技术选型，对整体的把握，要保证不会因为选型引起其他的风险，举个例子，如果在高性能存储方面选择redis的话，就要尽量保证网络的封闭性，避免公网访问；选择以cobol语言实现的各类产品时要考虑市场上开发人员数量少，承担更高的迭代成本等。

 应用架构类型：单体式、分布式、SOA架构

应用架构

    分有两种方式，

      一种是水平分，从功能类型划分，比如把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。

      一种是垂直分，以业务类型划分，比如ERP系统可以划分为三个独立的应用，这是面向业务广度的划分

     各个应用之间相互协作，主要体现在应用之间的相互通讯机制和数据格式，通讯机制可以同步、异步消息、共享访问等，数据格式是以文本、XM