需求规模庞大,业务数量和类型不断增多,业务相互耦合,不同业务相互影响。供应链有20多个行业,经销、代销、一盘货等各种商业模式,有跨境进口、国内业务、国际化业务,这些纵横导致系统复杂度大幅提升。
业务系统多,边界划分不清,系统间依赖复杂。如供应链商品和共享SELL、AIC和IPM,一直都有边界问题,一个大项目过来,边界问题就得讨论上好几天。
系统结构复杂,因为应对高并发、高稳定性等,功能性代码与非功能性代码混合,如业务代码混杂着各种兜底逻辑、灰度逻辑、重试等等,100行代码,可能业务代码不到30行。
商业环境复杂多变,商业流程、规则多变。商业环境变化快,今年国际化、智能商业路由、考拉融合一下子都来了,在设计上很难前期都规划好。
变化不可预测,软件系统变化也不可预测,带来设计挑战。
大部分需求横跨多个团队,需求传递低效,需要反复沟通,方案产出效率低。
团队角色多,业务概念多,没有统一语言,大家理解容易出现偏差。
分而治之,控制规模。
关注点分离,应对理解力挑战,领域模型与存储模型分离,业务复杂度与技术复杂度分离。
分层架构、分离核心,保持结构清晰,应对不可预测性挑战。
统一语言,应对协作力挑战。
定义公共术语,减少概念混淆。
沟通达成一致的提前,消除歧义和理解偏差,提升需求和知识消化的效率。
概念和代码的统一语言,连接概念和实现。
CQRS模式:领域模型在应用层下面,command才走领域模型;查询和搜索服务不走。
tunnel层,对接db、外部数据资源访问,领域和模型解耦,类似DAO。
外部通过SPI和模型交互,六边形的adapter模式。
serivce职责是:实体创建,持久化,跨实体操作等。
不同层使用不同数据对象,tunnel使用dataobjects,面向存储,需要和实体相互转换。
实体间有关系,可以动态加载关联对象;dataobjects只有数据,没有行为,一般也不会有关系。
边界 = 域或子域。
领域对象在领域内才有确切的含义。出了这个边界,不能确保还是这个含义,如苹果。
语言是有上下文的。
在不同的上下文中,职责和任务不一样。人有多个角色,在家里是爸爸、在公司是小二,职责和任务不一样。
有了边界,那么领域如何输出价值呢?一个完全封闭的系统没有任何价值。
常用的方式有:共享内核,防腐层等。防腐层:商品上游提供spi,spi不是直接对外开放领域模型,建立一层开放视图。采购域建立防腐层,收口商品的变更对本域影响。
识别和提炼领域知识,并体现在模型代码上,强调一次“并体现在模型代码上”!
防腐,保持模型不断演进,需要持续投入,保证DDD贯彻执行。
人的转变,开发思考方式的转变。
前3W描写用户故事,用户要什么,为什么要?举个例子,我作为采购小二,需要商品库存为0自动下架,因为有超卖风险,客户会投诉。
后面的When、Where、How是链路和边界分析,触发的条件是什么,要实现这个功能需要哪些域参与进来,分别提供什么能力?
APP层至上而下过程分析,模型层自下而上分析相结合。
能力下沉保持模型不断演进,能力下沉标准:复用、内聚。
微服务实战技术图谱
由微服务实战课程专家组出品,基于热门的微服务技术栈Spring Cloud Alibaba、Nacos,结合阿里巴巴工程师的一线实战经验,涵盖服务发现、服务配置、服务调用、服务熔断和Service Mesh等相关知识。