上一篇大致介绍了初入公司后参与的第一个项目原委始末，其实这几年都把时间耗这个事情上面了。为了方便各位看官理解，下面我先上一张系统设计的大概框图吧。

　　标红的是我当时参与的项目（ps：后来项目不可控了，公司无奈又招兵买马重新构架了一套公司自主研发的政务平台，总算挽回了部分局面，后面章节细说吧）。公司原来就有一套VB.Net开发的办公自动化系统，我的任务就是帮助将现有办公系统整合到平台中，说白了就是把部门和用户整合到Java开发的新平台中，提供入口从而实现所谓的单点登录功能，后来发现单点登录根本就不是那么回事！而药店监管这一块主要包含了平台监管端和客户端。客户端主要满足零售企业的日常进销存业务的需要，同时将业务数据通过API接口发送给平台端供政府相关部门实时监控企业的业务数据，上文说了我和本公司同事一起负责客户端的开发。

     有点跑题了，现在来说说技术选型吧。由于办公系统和客户端都要和平台发生关系，我也有幸参与了公司的技术选型的讨论会，呵呵…这次讨论会也让我增长了不少见识。讨论会是在南京研发公司那边开的。当时我们公司去了6个人，老板（ps：老板其实不懂IT，是个地道的IT门外汉！这么跟你说吧，平时打字都是用汉王的）、部门经理、技术顾问和加我一起的3个研发人员。南京那边1个技术总监（上文提到的Java大神），1个项目经经理和1个高级攻城狮。

　　讨论的主题先从系统设计层面入手，然后再讨论了开发框架的选择，最后讨论到了数据库的选择问题（客户端数据库选择这块狗血了！）。上面那张设计图是项目经理画的，然后分别跟我们解释了各个模块设计的用意，还提到了一大堆我当时闻所未闻的架构术语，如企业服务总线（ESB）、企业数据总线（EDB），面向切面服务（SOA）、软件即服务（Saas），平台即服务（Pass）、基础设施即服务（Iass）。艾玛，听的我真是云里雾里，不明觉厉！

　　开发框架如何选择这块是技术总监负责，不用我细说大家估计也猜出个大概，有点Java方面开发经验的同学都知道，用的是传统的SSH（spring+struts+Hibernate）开发框架，前端框架当时没有选择jeasyui、extjs、kendoui、bootstrap这种现在相对比较流行的框架，南京公司没有前端web开发人员，也别说美工了，所以程序员同时要兼顾美工和页面设计的活。另外还用到了一堆java web开发常用的第三方开源框架（不得不说java世界里真是一大片开源……），如：著名的工作流框架jBPM，操作pdf的iText，传统的日志记录框架log4j等等。

　　在数据库选择这块，客户为了缩减预算，事先已经声明不用Oracle，那数据库自然选择好用又免费的mysql，如果到这里数据库选择就结束的话，剧情就没这么狗血了，因为平台里涉及到客户端进销存系统（C/S结构）这块，当时两公司领导决定将大平台提升一个档次，给平台加了点“既响亮又文雅”的特效——云计算，云服务！从此政务平台就称为”政务云服务平台“了！既然牵涉到云，那总要用点云相关的技术吧，听说当时mongoDB表现不错，技术总监决定在客户端尝试一番（ps：除了总监之前玩过mongoDB之外，其他人都没碰过这东西）。进销存系统数据库就使用mongoDB吧，你看！这样就能实现云存储了！将客户端的数据都放到服务器上用mongoDB存储，后来我们大家回到公司，通过网上查询相关mongoDB的资料之后，都提出了反对意见。很大原因是：

1，首先对于进销存系统而言，很注重数据的关联关系。

2，mongodb是非关系的文档型数据库，不支持事务操作（ps：现在虽然说可以采用两段式操作，勉强算是支持了事务，但可操作性不是太方便，很多事务逻辑都需要人工处理并严格封装）。

大家都反驳mongoDB是不适合进销存系统的，并不是说mongoDB不好，而是不适合。为此当时我还在园子里写过一篇文章征求大家意见，有兴趣的朋友可以看看。可是总监给出案例说，国内著名的网站视觉中国就在用mongoDB，大家都说好！为此我也写了封邮件给视觉中国的老大潘凡。给的答复是这样：

　总监看完回复之后说，不是mongoDB不适合，而是我们不会用！然后又给我们吃了定心丸，说今后开发会辅助我们的，有问题就跟他请教就行了。当时我不是决策者，只能硬着头皮上吧！后来除了客户端数据库使用MongoDB之外，政务平台中负责接收客户端数据的业务监管系统也使用了MongoDB，相关企业档案信息也一并存入MongoDB。这样平台就“名副其实”的成为云服务平台了！也就在这一刻埋下了失败的种子。未完待续……

　　下一篇：项目开发之需求调研——净扯皮了！

　　ps：文笔不好，写的思路可能有点乱，也是想到哪写到哪，望各位看官轻喷，谢谢……