需求的发掘与挖掘

在很多的公司，开发人员通常的做法是接收产品的需求，然后设计、开发、测试与上线。
正常情况下，这样做是没有问题的，但是随着系统的壮大，会存在如下几个问题：

1. 这个需求在A实现会更好，但是产品经理对接的是B系统的开发，然后就在B系统中实现了。
2. 这个需求有类似的实现了，但是开发人员并不知道，接到需求后又实现了一遍。
3. 需求并不是客户真正想要的（虽然客户这样说），这个时候就需要深挖客户的需求。
4. 由于初期没有想清楚就急于上线，上线后就人想要优化这块内容了。（可能是算法，也可能是交互方式。）

保持系统的先进性

系统在一开始上线的时候，可能运行的很嗨，随着时间的推移，业务量的增长，数据库中的数据量越来越多，代码总的条件分支越来越多，会导致客户的体验越来越差，这个时候，就需要有业务架构师来解决思考这种问题，为保障系统的的稳定和性能对系统进行改造。
时刻系统的瓶颈

• 计算层面
  内存问题、CPU问题、网络问题
• 数据层面
  读瓶颈、写瓶颈
  常用手段：缓存、读写分离，分库分表、数据归档

面向领域分析与设计

• 对业务进行模型抽象
• 根据经验对业务梳理， 对业务系统进行分析、服务拆解、对耦合度高的系统进行聚合。
• 为开发团队的设计执行方向。
• 高内聚，低耦合，业务架构师，根据自身的经验与业务sense定义哪些业务模型要内聚，哪些业务模型之间该如何交互。

衡量系统拆分的必要性

有些人会为了一时之快，将系统拆的很细，但是由此产生的后果可能需要付出非常大的代价。

• 分布式事务问题
• 服务器资源成本问题
• 运维复杂度问题
• 系统依赖复杂度问题。

总结

业务场景千变万化，业务架构师随机应变。