开发一个业务逻辑复杂的系统,应该怎么样设计才能使项目的扩展性更好?

看到一篇 好文章,收藏一下

我在知乎关于《 开发一个业务逻辑复杂的系统,应该怎么样设计才能使项目的扩展性更好?》做的回答。

既然业务逻辑复杂,那意味着项目前期的业务建模、需求分析、分析设计极为重要,直接抛开这几个阶段进入技术实施开发阶段,不管套用什么设计模式、架构模式,系统的扩展性肯定难以保证。

项目的扩展性虽然最终体现为系统架构、技术实现的扩展性,但系统扩展性的根源在于系统业务架构及业务模型的扩展性。大家经常骂xx系统烂、扩展性差,大都将原因归结为技术实现烂,但总结那些成功的大型项目或产品的最佳实践,原因都会有:某某是业务专家,对xx业务很熟悉,能够衔接业务与技术。因此一个好的项目角色中,应该有行业专家/领域专家、业务过程分析师、系统分析师、软件架构师等角色,从业务架构、信息架构、技术架构保证系统的扩展性。

具体怎样进行业务建模,搭建良好的业务架构和业务模型,从而为技术架构、信息架构、技术实现奠定良好基础,有一些较为成熟的软件开发过程可供参考。例如 RUP(Rational Unified Process,统一软件开发过程)。一个标准的RUP工作流程包括:业务建模,需求分析,分析设计,实施开发,测试,部署,配置和变更管理,项目管理,环境。当然RUP只是一个方法论,且过于庞大,大部分项目很难完整执行其过程,需要根据实际情况进行裁剪,但其方法论对于复杂业务逻辑系统的建设具有指导意义。像互联网产品设计中常用的用例分析技术就源于RUP。

因此对于题主描述的一个复杂系统,标准的过程应当在业务建模,需求分析,分析设计,实施开发,测试,部署完整过程的分析设计(与开发语言无关)或实施开发(分析设计的成果映射为具体语言,例如Java、.NET等)阶段才考虑设计模式、架构模式的引入。设计模式的使用会经历僵化->固化->优化的阶段,类似禅修中“看山是山、看水是水”的三个阶段,才能体会模式的运用之妙。

值得强调的是:如果是偏交易(例如支付、金融)的系统,在考虑扩展性时候,一定要将信息架构、信息模型的扩展性纳入到考虑范围,此类系统数据模型至关重要,也不可能频繁变动。

上面描述方法的特别适用与传统软件、系统集成等需求偏稳定的项目,对于互联网偏创新性的项目就不一定完全适用了,此类项目的现实情况如下:业务模式不确定,会不停试错,验证模式;需求不停变化,要求能够快速响应;全新的行业,没有行业专家,没有行业标杆可借鉴(至多有跨界标杆可参考);此时候,类似精益创业、Scrum之类的敏捷开发模式更适合,但对于复杂的业务而言,业务建模->需求分析->分析设计的理念仍然值得参考借鉴。

最后,最最重要的是:完美系统的架构和扩展性是管理出来的、持续重构出来的。正如各大城市马路不停翻了再修、修了再翻的命运一样,中国大部分公司后任会不停否定掉前任的架构、系统,推倒再来一遍,然后等新系统刚开发出来不久,尚未上线或上线运营一段时间后,再换一帮人继续折腾,然后。。。

总结这么多年的经历,深刻体会到:再烂的系统和架构,如果能够强化管理、持续积累、持续重构、持续完善,都能够有机会成为完美的系统,完美的系统不在于其架构的牛逼和完美,而在于:符合公司的业务模式,能够完美支撑公司业务的高速发展和市场需求的快速响应。

你可能感兴趣的:(网站架构,架构)