当前位置: 首页 > 科技观察

一篇为大家带来DDD领域建模实践

时间:2023-03-17 00:47:40 科技观察

大家好,欢迎来到Tlog4J课堂,我是Jensen。今天给大家分享一个实际的DDD领域建模,结合我个人近三年的DDD实践经验,以企业级电商项目的DDD领域设计为切入点,希望能给大家带来帮助DDD的一些灵感。我将从DDD领域分析、DDD设计呈现、领域建模的实际案例来进行讲解。后面有彩蛋给大家~话不多说,开始DDD之旅吧~在DDD领域分析讲DDD之前,我们得了解一些基本概念,大家都知道DDD指的是领域驱动设计(Domain-驱动设计),如何理解DDD?DDD是事件风暴(品类划分),然后知道组织划分(中台)、系统划分(微服务)、代码划分/设计思维方式。这种理解可能比较抽象,但其实质是:通过把复杂的问题简单化,分而治之,降低复杂性。DDD的出现很符合当今流行的微服务架构。微服务架构有一个特别重要的命题——如何合理划分微服务,DDD的战略设计可以作为微服务划分的依据。我们谈论DDD。它实际上包括战略设计和战术设计。那么它们之间有什么区别呢?战略设计:业务层面的领域建模,强调业务领域模型的识别和边界划分。简单的说就是业务设计,和代码渲染无关。战术设计:工程层面的架构设计和模型设计,具体到微服务的应用就是完成微服务设计。两者哪个更重要?在我看来,战略设计比战术设计更重要。在实际生产中,业务会越来越复杂,代码也会越来越大。如果业务不分,表设计不分,系统最终会变成一个庞大的单体应用,叠加的需求会修改代码。当它发生时,它会移动整个身体。如果通过战略设计合理划分业务,各个业务的业务边界就会非常清晰。即使我们的代码不是使用DDD思想构建的,即使我们仍然使用传统的MVC架构,也不会影响业务的正常运行。战略设计是连接产品需求和开发代码的桥梁。应该如何分析领域驱动的战略设计?不用我们单独去探索,我们可以总结一下前人的一些经验:通用语言:它的作用是定义语境的意义,让语境定义领域的边界。事件风暴:在项目组、领域专家等的参与下,采用头脑风暴法分析用户故事,找出并建立领域对象。四色建模:按照时间发展顺序,“时间戳”概念标识“追溯文件”作用,直达业务核心数据;它强调可追溯性和执行效率。边界纸笔建模:回到一百年前,在那个没有电脑的时代,我们会用什么方法来做商业设计?我们可以用纸笔画表格写例子,管理的核心领域就是足够“数据”,增强数据完整性,避免过度设计。DCI建模:DCI大家可能听得比较少。DCI架构和MVC架构是同一个人,DCI建模通过角色扮演模型使领域模型易于理解,通过小类大对象的方式避免了神类问题;同时,也可以解决贫血模型和充血模型的争论,让模块更加内聚,耦合度低;当然,DCI建模也可以结合四色建模。那么,领域驱动的战术设计应该如何进行在我看来,大体上可以考虑两个方向:模型设计:比如用充血模型还是贫血模型架构设计:比如DDD/CQRS,cleanarchitecture,hexagonalarchitecture,cleararchitecture,DC我架构...到目前为止,我们已经了解了DDD的一些基本概念,那么为什么DDD对我们如此重要?我觉得DDD可以指导我们的业务设计,指导我们的代码实现,让维护更简单。DDD引导设计:从业务领域的角度划分领域边界,构建高效沟通的通用语言,降低新团队成员熟悉业务的成本。在不断沟通的过程中,通过提炼领域概念和业务抽象,建立领域模型,保持业务和代码的逻辑一致性。通过领域模型的分类和行为分析,保证业务实现的准确性。领域建模比数据库建模更轻量、更全面,数据库建模不能全面反映系统的所有特性和需求。DDD指导实施:不要过分依赖系统设计人员的经验背景,指导表格设计和代码实施。指导微服务的设计和拆分——划定清晰的微服务边界和可持续发展的微服务架构。易维护:从讨论、设计、到评审、再到实现,都使用领域模型进行沟通,可以作为系统业务的核心载体。限界上下文在微服务维度进行划分,服务拆分只需要去掉对应的限界上下文即可。降低业务需求迭代(如模型变更)带来的维护成本。这就是DDD对我们的意义。我们不能只站在发展的角度看业务问题,否则就会陷入发展思维的陷阱,无助于业务的增长。接下来我们回顾一下DDD的核心要素是什么——Domain是指在特定范围或边界内要解决的业务问题域。其核心思想是将业务问题域划分为子级域/核心域/通用域/支撑域,降低业务理解和系统实现的复杂度。聚合(Aggregate)聚合包括聚合根、实体和值对象。DDD中的聚合不等同于UML中的聚合。我们使用拥塞模型来设计领域模型的属性和行为,并识别聚合和聚合根。值得注意的是,微服务不应小于聚合,以免引入分布式事务的复杂性。限界上下文(BC)业务的通用语言有其业务边界。我们不太可能使用一个简单的术语来毫不含糊地描述一个复杂的业务领域。BC用于细分域以定义通用语言边界。BC包含一个或多个聚合,根据业务领域的概念划分为不同的BC。对应的Java代码层级就是最顶层的包目录结构。BC内部高内聚,一个业务行为在BC中尽可能使用线程级交互,保证ACID;BC之间的低耦合可以作为微服务设计和拆分的依据,当然微服务的拆分粒度还是需要结合企业运维的能力。BC之间最好使用领域事件进行交互,或者引入一个“翻译器”(或防腐层)进行通信,以保持BC之间的松耦合。DDD的核心要素就是这三个。如果我们了解了这三个要素,我们就可以开始做很多事情了。当然,我们还需要了解领域建模的一些难点,比如:领域发现:难点在于领域模型的概念提炼、模型分析和分类;领域划分:难点在于如何清晰划分业务边界和应用边界,如何划分控制业务设计的粒度,是自下而上的归纳划分还是自上而下的演绎划分;领域建模:难点在于如何识别聚合、聚合根、实体、值对象,如何建立领域模型之间的关系和核心交互等。DDD设计呈现——四色建模接到需求后,我们会在脑海里过一遍实现的代码。这个对于简单的CRUD来说不难,但是涉及到比较复杂的业务,一个场景足够我们沟通半天才能说清楚,那怎么办呢?其实很简单。我们需要一个载体来沉淀思维过程。当产品经理来找我们添加需求评估的影响范围时,新人会给他讲解,在做业务的时候,可以通过这个载体直观的呈现出来,这就是DDD设计呈现的魅力所在。这里我使用我个人比较容易使用的四色建模方法作为DDD的设计。四色建模法是一种领域模型的分析方法学,侧重于领域模型的分类,是一种表示方法。四色原型诞生于1990年代。它首先由PeterCoad和MarkMayfield[Coad92]提出,然后由DavidNorth[Coad95-97]扩展。它是一种广泛使用的系统分析方法。使用四色建模方法设计的四色图表达的类图是一个完整的动态图,包括时序图。它是三维的、多维的,区别于完全静态的数据库ER图。四色原型的四种颜色是什么?一起来看看:Moment-IntervalArchetype(简称MI)表示在某个时刻或某个时间段内发生的事情,比如销售订单、客户账单、Receipt记录等,用浅红色表示.PPT原型(Part-Place-ThingArchetype,简称PPT)代表参与不同角色的人或物,如商品、账户、店铺等,用浅绿色表示。角色原型(RoleArchetype,简称ROLE)抽象出一种参与方式,由人或组织、地点或对象承担,如客户、商户、仓储团队、金融机构等,用浅黄色表示。描述原型(DescriptionArchetype,简称DESC)属于数据类型的资源,目录类型的类别属性对象,或者可以被其他原型重复使用,如商品类别、支付方式、方法值对象等,并用浅蓝色表示。接下来,我们使用四色建模的方法对领域模型进行分析,分为四个步骤:建立时标原型:寻找需要追踪的事件,根据追踪到的事件寻找足迹。建立PPT原型:丰富模型,寻找时间尺度原型周围的人/事/物,使其更能描述业务概念。建立角色原型:进一步抽象出可以参与不同流程的角色。建立描述原型:用描述对象补充一些信息。这里需要注意的是,整个过程中会穿插原型之间关系/核心交互的注解。再来看一个电商DDD的四色图案例:领域建模的实际案例如下图所示,是金融领域部分模型和支付中心模型,这里只描述业务系统如何工作,不涉及表的具体字段设计。完整的模型图因为涉及到敏感信息就不详细展示了:领域建模就是这样一种建模,这里提一下一些设计细节:粉色指的是时间尺度的原型,就是核心业务产生的数据,基本上对应表的设计。模型属性不需要反映表的审计字段,如通用ID、创建者、修改时间、软删除标识等,模型行为只需要设计核心行为,常规的CRUD方法不需要写出去。设计需要权衡取舍。除了依赖、聚合等,BC中的模型还可以用箭头连接模型之间的核心交互,BC之间的模型之间可以用虚线箭头连接。这里我结合了DCI的建模方式(D表示数据,C表示Context,场景,I表示模型之间的交互)。对于代表业务独特性的属性,我用粗体显示,我再也不用和别人一起努力去分析用来构建这些模型的维度。对于尚未启动的属性更改(新的/修改的),使用红色标记。因为领域模型图指导着我们的业务开发。限界上下文的划分是一种非常主观的边界划分。为了让后续的代码可以灵活调整,Controller的URL设计中不需要添加boundedcontext。领域模型图就像代码一样,需要长期维护。这并不意味着设计已经完成并被搁置。这个很重要,微服务的负责人要有这个意识。我会继续深入研究DCI建模和DCI架构,我会把DCI留到下次分享~彩蛋!分享一个永久免费使用Pro****On在线绘图平台的方法:先买一年Pro****On个人会员(159元/年)。创建一个备用文件夹,将各种类型的图片放入其中。会员到期后,如果还需要新建地图,只需将其从备份文件夹中移出,修改即可使用。我个人一直在使用Pro****On在线绘图平台,因为它可以绘制脑图和各种UML图,支持在线协作,也支持嵌入站外的在线图片(如WIKI)。当然,它仍然是一个相对开放的学习设计的平台。你可以去它海量的模板库克隆别人的图片,看看别人是怎么做软件设计的。您也可以付费发布自己的盗图,要体验变现知识的乐趣,记得脱敏哦~好了,这次DDD领域建模实战课来了,你学会了吗(fei)?