软件架构-可视化
当我们在讨论系统时，往往都会说这个系统的架构是什么样的，在你口述的同时，如果能借助某些图表，效果会更好，传统的uml建模比较复杂，目前的软件工程大家更关注效率（这里我不谈敏捷开发），uml变得很不实用，那么探寻一种更简洁有效的“架构描述”方式变得比较迫切，笔者基于这个需求结合c4模型，uml，和自己的从业经验，总结了一套描述架构的方式.
1.系统上下文/系统全景图（System Context diagram）
2.系统应用程序架构图（Container diagram）
3.系统组件图（Component diagram）
4.组件明细图（Component detail diagram）
>组件API（Component interface）
>组件涉及的数据存储模型（data diagram）
>组件类图（Class diagram）
>组件时序图（sequence diagram）
5.系统物理部署（System deploy diagram）
上面我从人类比较习惯的认知事物的思维方式，自顶而下，层层推进的方式去描述我们的系统，每一层都从意图，结构，受众这3方面讲述了改成架构图的作用。
一.系统上下文/系统全景图（System Context diagram）
做为系统最高层次的抽象，不涉及细节，起到总揽大局的作用。
意图
系统上下文/系统全景图回答了下面几个问题：
-
我们构建的软件系统是什么？
-
谁会用它？
-
如何和现有it系统融合？
结构
结构，描述的是画系统上下文应该包含哪些元素，一般包含待构建的系统，使用该系统的人员，现有的it系统，以及上面3者之间的交互，在这里细节不重要
因为你画的是一个系统大局景观的广角视图，关注的重点在人和系统上，而不再技术和协议。
系统使用人员
主要分为2大类：业务用户和系统管理员。
关联IT系统
现有存在的it系统，需要与待构建系统进行交互。
交互
系统人员和待构建系统，待构建系统和现有it系统之前的交互，简单的链接线和简短的标注描述关键用例。
受众
直接的软件开发团队内部人员，外部技术人员和非技术人员。
示例
二.系统应用程序架构图（C4中的容器图）
应用程序架构图也是对软件系统较高层次的抽象，不过相对系统上下文，它进一步的说明高层次的技术选择。
意图
应用程序架构图，可以帮助你回复下面的问题：
- 构建系统的整体形态是什么样的？
- 高层次的技术决策有哪些？
- 系统内各个职责的分布？
- 应用程序是怎么交互的？
结构
首先明白那些是我们所说的应用程序指的是组成软件系统逻辑上可独立执行和部署的文件
web服务器：apache服务器， nigix服务器，微软的iis等；
应用服务器：jboss，ibm websphere，weblogic等；
sql数据库：mysql，db2等；
nosql数据库：redis，mongodb，hbase等；
搜索引擎：solr，elasticsearch等；
文件系统：oss，hdfs等；
定时器：corn等；
每个应用程序应用有自己的逻辑名称（web服务器），技术选择（nigix），应用程序的职责声名（负责反向代理和负载均衡）。
交互
应用程序之前的通信一般是进程间的通信，交互的标注需要关注如下信息：
交互的目的：为了传输数据，存储数据等
通信方法和协议： rpc调用，java消息，http服务，soap服务
通信方式：同步，异步
受众
直接的软件开发团队内部人员和外部技术人员；
示例
