在北航上课的时候，听《web services》的课时，老师拿出他们做的项目计划PPT给我们看。 里面有很多设计图，当时真的很感叹。 五颜六色的方块真的很整齐，那么整齐，有条不紊，我在想什么时候能做出这样的东西，变成了牛。 后来进入公司一看，这种东西很多，大多是制作产品的人们制作的，主要用于演示。 渐渐地，随着自己在公司的地位不同，我发现他们做的事情和我们设计的完全不同。
架构设计似乎是无形的，但她确实存在； 她虽然没有定案，但有门派之分，因人而异。 平时，我也会在网上找架构设计的文章，但大部分都是理论上的，实际上可以利用的成分并不多。 这里只谈我自己的体验。 顺便说一下，我并不鄙视理论。 相反，我崇尚理论。 因为如果一个认知没有理论支持的话，你的认知可能是不明确的也可能是错误的。 我没有理论基础，只能谈谈形而上学的所谓实践吧。 如果有不同意见，请多告诉我一些。
要说明软件产品的结构，绝不是图纸就能解决问题的。 我根据自己的经验，做了简单的步骤或分类。 她认为应该是产品原理图、系统结构图、核心模块图、层次结构图、业务流程图、接口协议表、网络拓扑图。
1、产品原理图
体系结构因产品而存在，脱离产品谈论体系结构是纸上谈兵。 产品设计正确与否是后续软件开发成功的基本保障。
当新员工加入你的团队时，他往往能参考哪些文档？ 大多数情况下，领导者往往会提供大部分产品设计说明书作为反馈。 啊，可怜的新职员。 如果有简单的产品原理图，再花几分钟说明的话，新员工融入团队的时间就会大幅缩短，心理上也会有底气，不会不知道自己在做什么。
我认为产品原理图需要以下特征。
1 )产品产生的背景
产品一定要解决某些问题，实现某些想法，她就是为问题而生的。 把问题说清楚，每个人都有自己的解决方案，之后大家就会说想说的话，体现出团队的力量。
2 )产品定位和性质
在我个人做的所有产品中，有一个产品不是完全独立的，总是与其他产品和平台有密切的关系。 明确产品与其他产品的关系非常重要，例如是旁路设备还是核心设备。 这是因为它关系到产品之间是序列化的还是并行的。 产品是定量分析还是定性分析，比如银行系统，对准确性和可靠性有很严格的要求，而数据挖掘的统计分析，对单个数据要求就不大。 因此，产品的性质非常重要，对今后核心系统的设计有决定性的影响。
3 )产品设计原理和思路
如果有前面的问题，就一定有解决的办法。 因为方法总是比问题多。 产品设计的原理主要是说明如何解决这个问题，使用什么技术或者公司已经有的技术来实现解决目标，也就是说我们最终要解决什么问题。 此时的问题非常具体，程序员一眼就知道自己要做什么。 剩下的问题是如何分工合作。
当然，产品经理画的方案图和我们程序员画的原理图往往有很大的区别。 毕竟各自的重点都不一样，我想程序员需要自己画产品原理图。 比较一下我以前项目的草图(请注意是草图哦)，看看能否想象出我的观点。
这是产品经理的剧本图
这是我自己画的原理图