.NET企业级应用架构设计系列之开场白
其实很久以前就想写点关于架构设计方面的东西,一直以来都没有最终落到实处。正好这段时间在做一个WEB架构,决定把和架构设计有关的内容写成一个系列文章。算是回馈CSDN提供的各种免费服务,同时给初学架构设计的朋友一点小小的提示。在我工作的六年多时间里,除了第一年是纯粹编码以外,其余时间都在做和架构设计有关的工作,当然也还一直在写各种各样的代码。也就是说,我本人其实也只有不多的经验可以分享,所以文中肯定有一些观点不能让所有人都认同。如有异议,可以发邮件和我讨论。
1、架构设计是件容易的事情。
对于不熟悉的或者没有架构设计经验的程序员来说,架构设计可能看起来很神秘,不知道究竟该如何入手,也不清楚该注意些什么问题。其实架构设计也只是软件系统开发中的一个环节而已,整个软件系统的开发和维护以及变更还涉及到很多事情,包括技术、团队、沟通、市场、环境等等。在分析和设计架构的时候也是有很多套路和原则的,只要我们按照一些最基本最简单的思路和方向去分析问题,就能得到一个大体满足实际情况的架构。前面我曾写过两篇关于人脑思考复杂系统的文章:《破解复杂性》以及《和SOA一起对抗复杂性》。这是软件开发中的方法论问题,可以贯穿于软件开发的多个阶段,包括架构设计、编码实现、后期维护等。掌握一定的原则,对架构设计能带来事半功倍的效果。
2、架构设计不是件简单的事情。
虽然架构设计是件容易的事情,但也不是大多数没有架构设计经验的程序员想象中的画画框图那么简单。把几台服务器一摆,每一台服务器运行什么软件分配好,然后用网络连接起来,似乎每个企业级应用都是如此简间单单的几步。但现实生活中的软件系统实实在在可以用复杂大系统来形容,从规划、开发、维护和变更涉及到许许多多的人和事。架构设计就是要在规划阶段都把后面的事情尽量把握进来,要为稳定性努力,还要为可维护性、扩扩展性以及诸多的性能指标而思前想后。除了技术上的考虑,还要考虑人的因素,包括人员的组织、软件过程的组织、团队的协作和沟通等。也许你会说那些都是项目管理上的事,和架构设计没关系。但一个团队成员无法实现的架构没有任何实际意义。另外,现在是解决方案满天飞的时代,很多事情都可以用多种途径来解决,如何在五花八门的选项中间做出决定,可能让很多人都头疼过。自己的经验、团队的素质、领导的要求、环境的压力以及市场的变化,够折腾了。
3、架构设计需要方法论的指导
所以,总的说来,在正确的方法论指导下,复杂的架构设计其实是件容易的事情。这些方法论的思路包括,至上而下的分析,关注点分离,横向/纵向模块划分等。有时候觉得架构设计决策就像是浏览Google Earth,实际上反映的是一种自上而下的决策过程。对问题的分解是软件思维的基本素质,可以有横向分解、纵向分解以及两者的结合。能不能有效快速准确的分解问题,是软件开发人员需要首先训练的项目。另外,架构设计中图形化的工具非常有用,它能把系统的结构和运作机制以图形化的方式表达出来。也正因为这样才有了架构设计就是画框图的误会。再者,架构设计是一个工程性质的工作,对当事人的实际从业经验要求较高。只有对市场上的各种技术有较全面的了解之后才有可能设计出一个尽可能满足各种设计约束的架构。
先说这么多吧,算是一个开场白。欢迎关注后面的详细内容。