浅谈如何做业务项目通用性、扩展性设计

标签：灵活   查询   角度   未来   分析   http   模式   完全   class   

前言

总结下如何设计项目方案。本文从通用、扩展两个角度去考虑项目该怎么设计，有哪些常用的手段。水平有限，望大家留言指正。

必要前提

• 充分的业务分析

1. 充分了解业务细节：需求分析或者prd阶段，要充分掌握需求的细节。细节可能会决定：数据从哪获取（多处数据源如何统一接入），如何流转（流程插拔），存储选型（那种存储方便扩展：比如nosql存储异构数据）。
2. 考虑不同业务线的差异：业务线的差异可能会导致：数据源不同、指标口径不同、规则差异。

• 未来3-5年的规划

1. 给未来留扩展空间：这个主要考虑业务的发展趋势，这个可以多和业务同学了解，或者看友商做法，
   系统要为这些未来的变化提前留好口子。
2. 不要过度设计：这个无需多说了，设计过度增加了过多的复杂度，后面的变化也是难以捕捉的，不要做无用功。

常用手段

• 设计模式、原则：设计模式本身就是提高软件的通用、扩展。遵循设计模式原则项目设计必要条件。具体参见：http://baijiahao.baidu.com/s?id=1589208155817565299&wfr=spider&for=pc
• 异构存储：

1. Nosql的强大之处就在于存储的灵活性，比如Hbase或者Mongo可以灵活存储业务数据，不care字段增减的变化。
2. 结构化的数据做非结构化功能。举个例子：mysql当成nosql使用，定义一个宽表，各种类型若干，定义一段文本，比如json，json里面维护业务字段与mysql字段的关系。

• 数据打平：面对业务的差异，比如指标，不同业务指标口径大多不同，要想架构通用，数据需要打平。数据打平可以在存储层、内存层、展现层。

1. 存储层：按照业务差异的公式，计算完成后存储，这样查询是就能保证数据同构，确保不同业务通用。
2. 内存层：说白了就是业务公式前置到内存层。然后通过计算公式计算结果，然后展现到上层。
3. 展现层：同2的思想。

• 规则引擎：可以说是屏蔽业务差异之银弹

1. 业务的差异完全可以使用规则引擎解决，通过配置化来解决业务差异。

浅谈如何做业务项目通用性、扩展性设计

标签：灵活   查询   角度   未来   分析   http   模式   完全   class   

原文地址：https://www.cnblogs.com/xiaogangfan/p/9291100.html