哪怕是顶级架构师都有自己设计的第一套框架，这个框架或许简单、或许稚嫩、甚至可能是一团糟。上一篇我分享了做架构师的前置条件，在满足大部分前置条件之后，踏入架构师的门槛其实没有想象那么困难。今天就来分享我设计的第一套框架，这个框架并不优秀，甚至有点可笑，但也有其存在的价值；另外，通过这个框架大家可以看看设计一套简单框架，其实很多人都能做到的。
谈架构先谈业务需求和背景。
15年底我进入一家四五百人的视音频公司帮忙（大屏、指挥室、展览馆等方面的视音频系统集成），打发读博前的时间（后来便留在了公司，放弃了读博）。公司的发展和利润都不差，营业额好几个亿，正在筹备创业板上市；公司之前是做硬件集成的，软件方面正打算通过和中国顶尖大学合作的方式来起步。
因为刚起步，产品、项目、需求什么的都不明确，我得到的信息量很少，少到无法正儿八经作出一个可用系统。但我也不能闲着，所以一方面我在各方之间努力了解需求，一方面根据现有判断做了一个特别简单的软件框架。如下图：
这是服务端的一个框架，思想非常简单：处理客户端来的命令，并进行反馈。画框架的方式也原始，没太多讲究。但这么“不讲究”的框架，在我们团队中也曾起到过实实在在的作用。今天就以这个框架（其实是介于模块设计和框架之间）作为讨论架构的开始，通过分析它给大家“框架”的直观印象。
1、应用场景：作为CS架构中的服务器端，处理客户端请求并给出反馈。因为需求不明确，所以目的非常简单和抽象。
2、设计要点：
（1）应用所需功能基于下层模块。所谓功能就指图片最上方的“登录”之类的，所谓下层模块就是“程序主体”那部分。
（2）将与功能及主逻辑不密切相关的部分从设计上解耦形成工具，就是“工具箱”那部分。之所以说从设计上解耦，是数据库、日志等在功能代码和主逻辑代码中被频繁调用，没有真的解耦；但设计上这些工具是独立设计的，不受主程序影响。
（3）分层。“程序主体”那部分，上层是传输层，往下是指令分发层，再往下是处理层，再下面是资源层或者说数据层。
3、评价：
（1）很幼稚。编码时也会发现有更好的做法。
（2）对编程工作具有指导意义。要实现一个功能有很多条路，但设计（哪怕是简单的设计），能让功能实现更优雅。所以比起用一个或几个大类、大函数来处理应用场景提出的需求，并由几个人分别实现（比如登录一个人写，设备控制一个人写），最后硬堆在一起（的确有团队是这么做的），这个简单结构所带来的设计对公共部分的抽离、对实体部分类的划分、函数划分是能起到指导意义的，事实也证明了这点。
我从来认为自己距离优秀的架构师还有很长的距离，但起码已经“混”到了软件部的经理带着二十来个人，算是脱离了纯粹的码农变得高级了一点点，而我在这个公司设计的第一套框架，便是如此简单和幼稚。所以有志于往架构师路上走的同学们要“不以需求小而不为”。从功能实现的思维里跳出来，用设计的眼光解决你面对的问题，尝试做一些功能上没有必要甚至添麻烦，但更有设计感的事，或许有助于你迈出架构师的第一步。