需求的发掘与挖掘
在很多的公司,开发人员通常的做法是接收产品的需求,然后设计、开发、测试与上线。
正常情况下,这样做是没有问题的,但是随着系统的壮大,会存在如下几个问题:
- 这个需求在A实现会更好,但是产品经理对接的是B系统的开发,然后就在B系统中实现了。
- 这个需求有类似的实现了,但是开发人员并不知道,接到需求后又实现了一遍。
- 需求并不是客户真正想要的(虽然客户这样说),这个时候就需要深挖客户的需求。
- 由于初期没有想清楚就急于上线,上线后就人想要优化这块内容了。(可能是算法,也可能是交互方式。)
保持系统的先进性
系统在一开始上线的时候,可能运行的很嗨,随着时间的推移,业务量的增长,数据库中的数据量越来越多,代码总的条件分支越来越多,会导致客户的体验越来越差,这个时候,就需要有业务架构师来解决思考这种问题,为保障系统的的稳定和性能对系统进行改造。
时刻系统的瓶颈
- 计算层面
内存问题、CPU问题、网络问题 - 数据层面
读瓶颈、写瓶颈
常用手段:缓存、读写分离,分库分表、数据归档
面向领域分析与设计
- 对业务进行模型抽象
- 根据经验对业务梳理, 对业务系统进行分析、服务拆解、对耦合度高的系统进行聚合。
- 为开发团队的设计执行方向。
- 高内聚,低耦合,业务架构师,根据自身的经验与业务sense定义哪些业务模型要内聚,哪些业务模型之间该如何交互。
衡量系统拆分的必要性
有些人会为了一时之快,将系统拆的很细,但是由此产生的后果可能需要付出非常大的代价。
- 分布式事务问题
- 服务器资源成本问题
- 运维复杂度问题
- 系统依赖复杂度问题。
总结
业务场景千变万化,业务架构师随机应变。
网友评论