初识DDD
理论上DDD可以指导所有业务系统的分析设计与开发。但从实践经验角度来讲,并不适合不加区分的在所有团队和业务系统建设时实施DDD,尤其是DDD推荐的CQRS架构,原因大概有以下几点:
但是单从系统的角度来衡量,如果系统符下几下几点之一:
当你所在的组织愿意为知识付费时,建议可以小范围内试点DDD,然后再推广,最终效果可能不能保证但至少它可能让你的系统增加以下几点优势:1、丰富的表达力(降低认知负担提升);2、集中的合法性校验和易测试性;3、不可变带来的线程安全;4、封装带来的柔性设计;
从众多实践团队的反馈来看,DDD并不适合所有初级人员(尤其是初级研人员)做深入研究。原因是:首先对业务的认知需要一个过程,同一业务模式在不同的场景、不同的组织中的形态差异很大,这些差异的了解和消化需要一个过程;其次DDD理论自身非常复杂,其阐述的概念理解起来非常困难,部分概念最终需要以代码的方式映射出来。前者涉及业务建模,后者关乎架构设计的合理性,这两者都属于顶层设计,一旦出现偏差纠错代价可能是非常巨大的,尤其是采用充血模型来编码DDD的团队。
在实践过程中,针对技术团队,我把DDD的目标人群分为两类:
上述的目标人群定位可能会与DDD作者所阐述的观点相悖,实际并不矛盾。DDD强调技术架构师和领域专家的配合,尤其是领域专家是不可或缺的角色,现实情况是组织中很少存在这样的人,也不是通过高薪就可以招聘到的。最切实可行的方式是从内部培养。把有潜力的T型人才培养成n型人才,即领域专家,笔者倾向于培训有潜力的技术架构师,下面对上面的两类人群再补充两点说明。
不同企业里架构师Title的同学的工作内容可能是完全不同的,从编码参与度来讲大概可以分为三类:1、完全或很少写代码;2、只写核心代码;3、参与业务需求的开发,指导高级工程师设计开发核心代码;
怎么理解呢,首先软件架构设计的影响因素很多,一般来讲都需要适当的抽象,如果架构师只设计不参与编码,即使有很严格的过程把控,实际上都经常会出现设计与实现不符的情况;其次,在确定核心代码应该由核心研发来编写这个结论之前,我们需要回答两个问题:1、如何定义核心代码?2、核心代码开发工作量占系统开发总工作量的比例是多少?如果业务系统没有太多带有门槛的核心技术,个人还是建议架构师充当一个导师的角色同时多参与非核心代码的开发工作,这样才能结合业务并更贴地气的指导低级开发工程师。
DDD的践行是基于学习试验、质疑、再学习和重建模的过程,认知很重要。人类对事物的认知无非是基于时间和空间的,需要丰富的阅历和一个时间的跨度。
相信大家都会有这个经历,小时候调皮的时候家长会经常告诉我们:”学习是给自己学的,不是给别人学的!”或者是”别人家孩子系列”。我当时能理解的是学习好也就是期末多得张奖状或者领点铅笔这样的奖励,也只局限于这些了。如果把 ”学习” 比做DDD,笔者回忆了一下大概是这样的:
回到软件设计主题上来,以商品中心为例,简单的商品中心一般只需关注类目、SKU、SPU、库存等几个关键设计即可,业务发展初期与之匹配的运营系统和客服系统一般会滞后建设,此时的系统见上图第一行部分称为1.0时代,大概表现为:
在1.0时代,如果负责系统实施的团队不了解运营和客服体系相关的知识,未在1.0中提前考虑和设计,那么当2.0时代到来时那么对原来系统的冲击很可能将是毁灭性的,比如考虑下列几个场景:
上述的例子中1.0时代影响系统建设的最重要的技术成本,但到了2.0时代在架构上就要考虑组织架构、跨部门沟通协作、系统集成、甚至KPI考核等因素。多数年轻的技术人员对这些隐性的成本和风险是没有感知的。
对DDD的应用也是,如果认知不够或是不统一,很容易出现套用的现象发生,就好比初学23种设计模式时,咋看咋明白咋用咋别扭,纠结根本就是认知不够。建议初级工程师在没有足够积累的时候尽量采用跟随的策略参与到DDD的建设中。
下面是实践积累的经验步骤(本文档中存在先后顺序的列表会以数字方式做为列表符,没有先后顺序的列表会以方块的形式做为列表符),仅供参考:
如果DDD能在团队中得到推广,实施对象往往以老系统居多,就意味着对原有系统做重构(而且是动了底层模型),这个重构往往是即不能影响线上稳定运行也不能影响日常的业务需求迭代。
为了降低重构风险以及改造成本,在实践DDD之前,首先要对老系统进行隔离改造,下面是笔者在老系统改造过程中积累的一些经验,详细包括:
经过上述改造后,老系统在X(功能模型)和Y(架构层次)两方面都做到了隔离,如果做的彻底,我们的系统架构现在应该是一个网状结构。接下来就可以应用DDD设计方法论进行重构了。
没有一种设计可以适配所有的场景,DDD也是如此。在践行时讲究的是变通而不是硬套,以下是实施DDD以来踩过的一些坑,希望牢记:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。