前端DDD总结与思考

作者:程波
掌门教育业务系统前端架构师

软件开发架构演化与DDD起源

单体服务架构:大概10年前,我在武汉工作的时候,甲方客户购买我们的产品,一般都是连着设备一起购买,一套软件系统,一台惠普或者戴尔的企业级服务器,再加一个黑色的铁盒,销售部可以卖小几百万左右、外加每年维护费用,这就是一个非常典型的单体服务开发、运作的方式。

SOA服务化、微服务架构:前端开发同学普遍离业务域结构比较远,一般比较难真正意义上去理解服务化与微服务,我个人对微服务和SOA区别的理解,SOA服务化,往往侧重某一类具体业务场景下功能的实现,它必须有一个明确的业务场景来做支撑。微服务更加侧重类似区块链这种去中心化结构,它的开发、部署、发布等等可以完全独立隔离。

中台化架构:中台化除了包含SOA、微服务这个技术结构以外,业务场景层面,它更推崇信息智慧化,大数据、深度学习、神经网络、人工智能,他的原材料可能是用户个体数据信息,但作用结果并不是直接反哺在单个应用个体,而是交给公司运营、市场、供应链等等兄弟平台,兄弟部门来做下一步决策。

中台化最典型的场景是类似金融、保险、电商等行业,我做过一个生鲜次日达项目,生鲜特别是肉类,当用户量上来了,采购少了补采来不及,采购多了,当天就坏了,所以,对于我们技术部来说,最大的挑战在于,为什么我们能提前一天就知道5吨肉刚好就能卖完,我们能够实现这样的业务场景支撑,就是信息智慧化带来的结果。

DDD(领域驱动设计)起源于2004年前后,却随着SOA、微服务开始普及。

DDD应用场景

在我看来,业务领域层是一个互联网公司最核心的部分,它是一个公司业务模式-技术化的载体,会有非常多的职能方一起参与进行开发,比如公司的业务架构师、产品经理、其它兄弟部门。

但随着参与人多了,沟通是一个问题,特别是岗位职能完全不同,鸡同鸭讲、对牛弹琴,而对于复杂的业务、关联方更多,沟通成本可想而知。DDD就是面向这种场景下的解决方案,它是对业务需求的高度抽象,根本目的是帮助我们理解和分析业务,在多方沟通、交付中,统一建模理解,以指导进一步的技术实现。

DDD的优势

项目健壮性:对于技术同学来说,谈到代码健壮性,我们往往会提到高内聚、低耦合,这对于不少开发同学来说,在业务开发最开始的时候,并不是什么大问题,在我看来,健壮性真正的挑战来源于,是在不断变化的业务需求、和开发时间之间的冲突下,日积月累形成的,而DDD推崇的是,对业务需求的高度抽象,因此,它可以在最根本上减少我们业务需求变化的可能性,从而带来业务健壮性上的提升。

业务灵活性:对于DDD设计架构的项目,因为核心实现、边界切割非常清晰,在很多业务场景下,胶水层或者controller层的实现,类似于积木堆砌,因此可以预见的是,在这种模型下,只要核心服务不发生重大变更,它的业务灵活性将非常强韧。

工程易维护:DDD只是一种设计思维,它的作用场景主要在于业务架构师、产品经理、技术开发等等多方协同工作,因此,在工程维护性上,相对于我们常说的代码可读性等等,它可以影响更多兄弟部门,可谓是降维打击。

DDD对前端的挑战

前端职能面向交互:对于前端开发同学而言,我们主要的工作量在于交互层面的实现,很少会直观的去关注,在一个业务场景下,为什么用户可以去抽奖,为什么用户抽中后,可以通知用户领奖,对于前端开发而言,对于一个业务闭环背后的“为什么”关注比较少。

设备、场景裂化严重:我以前做过一个需求,也是一个抽奖的功能,但是,要求在微信端、非微信H5端、PC端、还有微博端都做实现,这里就产生了一个问题,如果我的业务逻辑在C端实现,同样的代码,我必须实现很多份,一个小小的变动,我可能需要发版多次,最终,方案逻辑只能是放在server端,所以,这是设备、场景裂化带来的局限性。

业务沉淀驱动力不足:受限于我们在业务闭环上的关注度、设备、场景裂化,这就导致我们很难再抽出额外的精力去关注业务沉淀。

掌门教育DDD实践

我们团队在一起沟通Mapping项目需求的时候,举过一个例子,未来我们业务应用的开发方式,应该像带烟囱的工厂,工厂厂房是聚合平台,它是一个黑盒,厂房上面一个个独立的烟管,就是我们一个个独立的应用出口。

比如,政府机构提供了一个查询用户身份证的API,A、B、C三个游戏公司的应用,对接实名认证功能,或者用户充值,对接支付宝、微信的支付功能,他们之间的业务界限应该非常清晰。

因此,对于我们做规则模块来说,其中非常核心的部分,就是如何帮助我们的C端开发者,做好业务领域边界划分。

其次,我们Mapping项目开发过程中,最开始在做状态模块、决策模块,或者流程模块、数据处理模块的时候,我一直在考虑是否要合并做,因为它们之间的关联性非常强,最终我们选择分开来实现,后来在做Mapping二期需求设计的时候,就非常庆幸之前的选择,因为我们发现新的模块对一期部分功能模块依赖也很强,如果一开始我们设计没有做好分离,我们的引用成本就很高,需要做多层不同数据字段值校验,而分离干净后,如果引用部分是一个StateNode模块,或者是一个Schema模块,我们可以只对类型做校验,而不需要做字段数据值校验,这能够帮助我们规避很多无意义的问题。

总结与思考

1.业务高内聚、低耦合:未来,我们技术开发同学,将不可避免的,需要去面对更复杂、更多变的业务需求,应对之道,在我看来,除了我们在做代码实现的时候,需要采用更合理的设计模式、分层开发之外,我们更需要能够紧跟公司具体的业务场景,以业务领域驱动为沟通基础,对齐一条线上的OKR,才能做到事半功倍。

2.我前几年看过的一个数据,大概意思是,我们现在每天产生的数据,可能都比21世纪以前的数据量加起来都多,这么海量的数据,背后代表的将是海量的业务场景,可想而知,我们的业务需求多样性也将是海量的,这也就对我们如何能够快速理解、消化、并对业务进行技术实现,带来很大的挑战,但在精细化运作的时代,一个公司不可能像过去那样单打独斗就能有一番作为,一定是多人、多方协同下去实现业务,从这个方面出发来看,我觉得DDD大有可为。

3.之前跟朋友开玩笑,举过一个例子,我说以前大家玩Dota,会补刀、会选择合适时机放技能,就算厉害了,过了两年,如果不会补刀、择机放技能,就是菜鸡了,游戏还是同一个游戏,但是有了沉淀、有了积累,慢慢大家就拉开差距了,DDD对于我们技术开发同学来说,其实是一个与公司业务发展共同成长中,一个很好的桥梁。

posted @ 2021-04-16 17:16  白玉兰开源  阅读(68)  评论(0编辑  收藏  举报