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