现在我们分析一下一个端到端业务流程的环节组成（模块）之间的依赖，例如，一个商城的基本交易流程为：商品接入、端到端用户注册签约、商品管理、商城商品浏览与搜索 、入购物车、下订单、支付、发货与退货等，经过分析我们会发现一个基本的规律：
1、下一个流程环节往往会依赖上一流程环节或前序流程环节，而不依赖下一流程环节，因为后面的流程业务跟它没关系
2、下一流程环节的操作和管理，往往会查询所依赖的，上一流程或前序流程环节的业务实体，以及它的状态、类型等规则，体现为上一流程环节或前面环节的业务实体的部分属性的查询，状态、规则的查询与判断
3、对于同一端到端用户，流程上往往应是闭环的，比如对于经销商，有商品的接入，订单的接收，有商品上下架管理，也有发货、退货管理，也就是说，这个用户群的业务应是完整的，否则它的业务就无法办完
4、企业的客户，或者说用户群，由于业务模式的不同设计，可能会产生多个端到端流程，但这些不同的端到端流程，基本在流程上是没有藕合的，交易数据也会是基本独立的
5、不同的端到端流程，往往会发生在同样几个端到端用户身上，但不应产生流程上的藕合，否则就说明这个流程架构的设计就是有问题的，目标不清晰的
6、多个端到端流程，往往会有一些企业级共享主数据和规则，这些数据代表了企业级的共享数据与业务规则，这就是为什么许多企业会搞主数据平台和规则平台的原因
不同的端到端流程，往往会拆分会一个个子系统，而一个个环节，往往会拆分为一个研发团的队，那么，团队对业务敏捷，必体现了应对流程变化的敏捷。那么如果你的流程架构不是清晰的，交织在一起的研发团队，必然也会交织在一起，这样的团队还能够敏捷的起来吗？
所以，消除端到端流程之间的藕合，减弱流程环节之间的藕合点，消除服务层之间的双向藕合，就是一个成功的业务敏捷研发团队的基石。
而前端应用的组织，往往会考虑不同用户群的统一入口，而拆分为不同的应用，但它背后的业务，很可能是与别的应用属于同一业务范围，比如，一个订单，要去运营后台应用中去审批，它其实还是属于订单管理的范围，只是表现层应用拆分了，而服务层、数据层也拆分，就会产生应用之间严重的藕合，同一业务范围的服务层、数据层应集中，而不能按前端应用简单拆分。否则就会产生大量接口，以及事务一致性如何保证的问题。