DDD(领域驱动设计)

家电修理 2023-07-16 19:17www.caominkang.com电器维修

学习并尝试用各种的设计模式去分析需求编写代码。在这一过程中并没有觉得重构或者代码的复用、优化觉得特别爽的感觉。怎么样都觉得这个代码还是不够好。

第一次接触到领域驱动设计的时候,是在看到了某个视频说到了这点,并且提出了领域驱动设计相关的知识。看完了还是觉得一脸懵逼,至少现在还是。想想就干脆写了文章进行自己的理解以及,可能很多理解偏差了。

 

了解领域驱动

软件开发不是一蹴而就的事情,我们不可能在不了解产品(或行业领域)的前提下进行软件开发,在开发前,通常需要进行大量的业务知识梳理,而后到达软件设计的层面,才是开发。而在业务知识梳理的过程中,我们必然会形成某个领域知识,根据领域知识来一步步驱动软件设计,就是领域驱动设计的基本概念。

DDD是一种以领域为核心的设计和开发理念。DDD通过维护一个深度反应领域的概念模型,以及提供可行的经过实践校验的大量模式来应对领域的复杂性。(它并不会降低复杂性)

领域驱动与数据驱动区别  

通用语言

DDD分层架构 用户界面/展示层负责向用户展示信息以及解释用户命令。应用层用来协调应用的活动,不包含业务逻辑,不保留业务对象的状态。但它保有应用任务的进度状态。领域层本层包含了关于领域的信息,这是业务软件的核心所在。在这里保留业务对象的状态,对业务对象和它们状态的持久化被委托给基础设施层。基础设施层其他层的支撑库存在。提供了层间的通信,实现了对业务对象的持久化。包含了对用户界面层的支撑库等。

 

 

 

层次说明controller提供服务的访问层,目前采用RestController的方式,也做基础数据格式校验的业务。service对应上图中的services部分,主要做4类事情:1、开启事务与事务消息,2、适配并调用Executor层,3、业务拓展,4、多个Executor的编排组装。(协调应用的活动,不包含业务逻辑)convertor适配层,适配层的存在也是为了避免各层次间的强依赖,为了更清新的划分清楚层次,如mand对象将不直接依赖vo对象,而是通过convertor或构造数据做适配executor具体业务命令的逻辑编排与执行,这是业务逻辑处理的关键地方,遵循CQRS分为Command与Query,executor是资源层的操控者。extension业务扩展层,可扩展多种业务实现,COLA提供了全局的策略规范。extension会在service层被调用domain洋葱图的核心部分:领域层,domain领域可细分为model与service(action)eventevent在架构图中属于资源层,event作为解耦系统的耦合度起到了非常关键的作用,也为解决事务问题提供了标准pojo数据dto对象,分为mand/vo/co/ao... 等不同的dto对象repository资源层相对来说比较广泛,最基本的是对db的操作,对其他模块的操作(feign),对搜索引擎或消息队列的操作都属于资源。可细分为:feign、db、search、message 领域对象的生命周期

每个对象都有生命周期,如图所示。对象自创建后,可能会经历各种不同的状态,直至最终消亡——要么存档,要么删除。管理这些对象时面临诸多挑战,稍有不慎就会偏离MODEL-DRIVEN DESIGN的轨道。

 

主要是为了在整个生命周期中维护完整性,防止模型陷入管理生命周期复杂性造成的困境中。解决这些问题,主要是靠AGGREGATE ([ˈæɡrɪɡət , ˈæɡrɪɡeɪt] 聚合)、FACTORY([ˈfæktri]工厂)、REPOSITORY(

[rɪˈpɑːzətɔːri]存储库)三种模式。

是AGGREGATE(聚合),它通过定义清晰的所属关系和边界,并避免混乱、错综复杂的对象关系网来实现模型的内聚。聚合模式对于维护生命周期各个阶段的完整性具有至关重要的作用。接下来,我们将注意力转移到生命周期的开始阶段,使用FACTORY(工厂)来创建和重建复杂对象和AGGREGATE(聚合),从而封装它们的内部结构。,在生命周期的中间和末尾使用REPOSITORY(存储库)来提供查找和检索持久化对象并封装庞大基础设施的手段。

 

 

Copyright © 2016-2025 www.caominkang.com 曹敏电脑维修网 版权所有 Power by