产品模板化与系统边界引发的思考

系统划分边界确定一直是一个比较难搞的活，拆分之后的系统真的能做到职责单一？？？

这就涉及到技术上的思考坚持CAP、引入Base思想.....

不纠结了吧，今天分享一个阿里的大牛的经验。

 

1、产品的定位需设计的模板化的做法，比如我有一个订单系统，需要整合各个业务系统的订单，而每个业务系统的业务属性差别很大、业务单据状态运转也有差距，那这该如何取舍？

 

• 坚持模块解耦，随时可替换，引入第三方更成熟更先进的产品模糊，
• 模板化的模块迭代周期不一样，相互影响周期不一，测试力度，
• IT属性不一致（模板化的各个模块访问量、并发量、部署的规模），

 

2、产品界限确定后，就会有些控制权、中间地带的产品服务比较纠结，比如我是财务系统C，他是一个支付系统P，另一个是交易系统T，现在C发出指令调用P，P又需要调用T，而P和C有界限不该这样做，这涉及到工作量及维护成本（总有一方维护着不擅长可能多变的服务接口），这时怎么办？

      这个一直以来都是难题，涉及到一个中间模块，中间模块由它来构建来负责，这样就比较合理，那怎样做呢？服务组合最佳，各自继续提供单一的服务，由ESB来组织中转维护。