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

简介:

前言

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

必要前提

  • 充分的业务分析

    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. 业务的差异完全可以使用规则引擎解决,通过配置化来解决业务差异。
相关文章
|
6月前
|
测试技术
功能性模型在架构设计中的应用
功能性模型在架构设计中的应用
|
5月前
|
消息中间件 存储 数据可视化
【结合业务需求给出合理的技术解决方案,改进现有模块功能,提高系统的可扩展性,封装性,稳定性】
【结合业务需求给出合理的技术解决方案,改进现有模块功能,提高系统的可扩展性,封装性,稳定性】
|
5月前
|
消息中间件 设计模式 缓存
聊聊结合业务需求给出合理的技术解决方案,改进现有模块功能,提高系统的可扩展性,封装性,稳定性
聊聊结合业务需求给出合理的技术解决方案,改进现有模块功能,提高系统的可扩展性,封装性,稳定性
|
10月前
|
测试技术
【系统架构】可靠性测试用例设计时重点考虑的特殊情况
【系统架构】可靠性测试用例设计时重点考虑的特殊情况
69 0
|
11月前
|
设计模式 监控 Java
设计模式如何提升营销自动化业务扩展性 | 引擎篇03
设计模式如何提升营销自动化业务扩展性 | 引擎篇
112 0
|
11月前
|
设计模式 数据可视化 Java
设计模式如何提升营销自动化业务扩展性 | 引擎篇01
设计模式如何提升营销自动化业务扩展性 | 引擎篇01
138 0
|
11月前
|
设计模式 算法
设计模式如何提升营销自动化业务扩展性 | 引擎篇02
设计模式如何提升营销自动化业务扩展性 | 引擎篇
|
自然语言处理 架构师 项目管理
技术方案设计的方法
前段时间接手了一个还处于方案设计阶段的工作,我重新做了设计。觉得新方案比旧方案业务清晰明朗、解决了旧方案的缺陷。我就很高兴,跟同事聊这个事情。同事就问我是怎么想到这些的呢。 我说了一些细节的,但是没有把核心本质讲出来。我觉得这是个很难回答的问题。因为一个方案怎么更合适,主要因素包含业务理解、个人经验、思维逻辑。这3个要素一般都是靠经年累月的积累才获得的。从这些中提取出别人可以学习和使用的方法确实不是一会儿就能想出来的事情。
技术方案设计的方法
|
存储 缓存 负载均衡
高可扩展性系统的设计(上)
高可扩展性系统的设计(上)
275 0
|
存储 移动开发 运维
高可扩展性系统的设计(下)
高可扩展性系统的设计(下)
128 0
高可扩展性系统的设计(下)