系统划分边界确定一直是一个比较难搞的活,拆分之后的系统真的能做到职责单一???
这就涉及到技术上的思考坚持CAP、引入Base思想.....
不纠结了吧,今天分享一个阿里的大牛的经验。
1、产品的定位需设计的模板化的做法,比如我有一个订单系统,需要整合各个业务系统的订单,而每个业务系统的业务属性差别很大、业务单据状态运转也有差距,那这该如何取舍?
- 坚持模块解耦,随时可替换,引入第三方更成熟更先进的产品模糊,
- 模板化的模块迭代周期不一样,相互影响周期不一,测试力度,
- IT属性不一致(模板化的各个模块访问量、并发量、部署的规模),
2、产品界限确定后,就会有些控制权、中间地带的产品服务比较纠结,比如我是财务系统C,他是一个支付系统P,另一个是交易系统T,现在C发出指令调用P,P又需要调用T,而P和C有界限不该这样做,这涉及到工作量及维护成本(总有一方维护着不擅长可能多变的服务接口),这时怎么办?
这个一直以来都是难题,涉及到一个中间模块,中间模块由它来构建来负责,这样就比较合理,那怎样做呢?服务组合最佳,各自继续提供单一的服务,由ESB来组织中转维护。