一次架构设计的摸索

最近部门安排我参与一个后台计费系统的项目，作为架构设计人员，这一两周的主要工作就是推演PD的UC和相关的架构设计，一个阶段的工作下来有了些心得。

• 这种非底层技术性项目的架构设计最关键的是业务架构设计，对业务的把握是所有架构因素中最重要的因素。项目最开始我把精力放在了如何用些花哨的模式搭建可扩展性强的框架，可后来逐渐发现这些不是大家最需要的，大家最需要的是通过技术实现的角度把业务上的各种需求整理出来，勾画出清晰的业务流程。所以，我感觉对于这种项目，最开始也是最重要的架构设计工作是理解需求并帮助PD调整和优化需求，然后用流程图、类图和时序图的形式做业务架构设计。

• 对于这种需要多方合作完成的项目，一定得站在整个系统的高度看待自己所参与的子系统。如果单纯只站在自己这个子系统的立场上，设计方法可以有很多种，但要兼容于其他子系统的话，将会有很多限制，所以，架构设计之初，一定得多和其他子系统的接口人多沟通，识别出其他系统对自己的限制，也得学会影响他人，用适当的方式让合作朝着有利于自己的方向进行。

• 要珍惜架构评审的机会，一定得在架构评审时讲清楚自己的设计意图，使他人得到充分的理解，不要试图为了让评审会议和谐而尽量掩盖一些关键点，多让他人PK自己，一方面可以多吸收他人的意见，再则，让风险点尽量暴露在架构设计阶段，不要留到编码甚至是测试阶段。当然，被人PK的过程不容易，这也是一个优秀的架构师需要经历和磨练的过程，这其中很关键的是要培养自己快速理解他人想法并作出反应的能力。
• 架构文档只是架构设计开始，关键是架构得到实施。以往写完架构文档搞完架构评审后，就感觉架构设计告一段落，实际上这个时候所作出的工作价值为0，只有当架构设计得到开发和测试人员的认同，并在实际编码中得到彻底贯彻和实现时，架构设计才体现了它的价值。因此，这次做完架构设计后，我会尽力对每个开发和测试人员传播设计思路，并在每个开发环节PK架构设计，不断重构和优化架构设计。

• 在底层框架上需要识别出最关键和最有风险的点，把精力放在最需要花时间的上，不要试图去找些花哨或前沿的技术方案照搬过来，这是很危险的事情。在架构上，最好的技术是简单、可行性高、能解决问题，并被自己孰知的技术。如要用一些开源框架，最好是能对其原理甚至源码有些了解，在出现问题时，能深入其中。

总之，架构设计绝不是套几个设计模式，配几个通用框架的事情，是要真正深入到每个业务环节，考虑到实施过程中每个风险点，让设计的各个细节得到彻底的实施