DDD项目落地之充血模型实践

ddd,项目,落地,充血,模型,实践 · 浏览次数 : 442

小编点评

**背景:** * DDD分层架构中的实体设计是一种方案,可以使关注点聚焦于业务实现,提升开发效率、提升可维护性。 * 实体设计充血模型是一种实体设计的一种方法,简单来说,就是一种带有具体行为方法和聚合关联关系的特殊实体。 **实体设计:** * 实体:定义在领域层,是领域层的重要元素,从领域划分到工程实践落地,都应该围绕实体进行。 * 充血模型:实体不带有任何行为方法,也不带有聚合关联关系,作用基本相当于值对象(ValueObject),仅作为值传递的对象,和传统三层项目架构中的实体具有相同作用,不建议使用。 **关键点:** * 领域服务->聚合->聚合根->实体->贫血模型->充血模型聚合与聚合根:聚合是一种关联关系,而聚合根就是这个关系成立的基础,没有聚合根,这个聚合关系就无法成立。 **问题:** * 实体设计中如何处理行为代码量过多导致实体内部臃肿膨胀的问题?

正文

背景:

充血模型是DDD分层架构中实体设计的一种方案,可以使关注点聚焦于业务实现,可有效提升开发效率、提升可维护性;

1、DDD项目落地整体调用关系

调用关系图中的Entity为实体,从进入领域服务(Domin)时开始使用,直到最后返回。

2、实体设计

充血模型是实体设计的一种方法,简单来说,就是一种带有具体行为方法和聚合关联关系的特殊实体;

关于实体设计,需要明白的关键词为:领域服务->聚合->聚合根->实体->贫血模型->充血模型

聚合与聚合根:

聚合是一种关联关系,而聚合根就是这个关系成立的基础,没有聚合根,这个聚合关系就无法成立;

举个例子,存在3个实体:用户、用户组、用户组关联关系,这3个实体形成的关联关系就是聚合,而用户实体就是这个聚合中的聚合根;

实体:

定义在领域层,是领域层的重要元素,从领域划分到工程实践落地,都应该围绕实体进行,DDD中的实体和数据库表不只是1对1关系,可能是1对多或者仅为内存中的对象;

贫血模型:

实体不带有任何行为方法,也不带有聚合关联关系,作用基本相当于值对象(ValueObject),仅作为值传递的对象,和传统三层项目架构中的实体具有相同作用,不建议使用。补充说明:一般我们使用的DTO就可以被当做是值对象

充血模型:

实体中带有具有行为方法和聚合关联关系,行为方法是说create、save、delete等封装了一类可以指代行为的方法,比如在用户实体对象中具有用户组实体的引用,这样当我们需要操作用户组时,只通过用户实体进行操作就可以。

工程实践中,建议采用充血模型,好处是隐藏胶水代码,提升代码可读性,使关注点聚焦于业务实现。

充血模型在实践中的问题:

行为代码量过多,导致实体内部臃肿膨胀,难以阅读,难以维护,对于这种问题,我们需要根据实体行为的代码量多少来采取不同的解决方案。

解决方案:

场景1:行为不会导致实体臃肿的情况下,在实体中完成行为定义

public CooperateServicePackageConfig save() {    
    // 直接调用基础设施层进行保存
    cooperateServicePackageConfigRepository.save(this);    
    return this;
}

场景2:行为导致实体臃肿的情况下,采用外部定义行为的方式,核心思想是借助其他类实现行为代码定义,将臃肿代码外移,保留干净的实体行为:

1)创建工具类,将某个实体中的行为定义其中,实体负责调用该工具类

public CooperateServicePackageConfig save() {    
    // 将处理过程放在工具类中
    ServicePackageSaveUtils.save(this);   
    return this;
 }

2)创建新实体,将该实体的使用场景明确至某个细分行为,比如一个聚合根(ExampleEntity)的保存可能涉及到5个实体的保存,那么我们定义一个ExampleSaveEntity实体,专门用来处理该聚合下的保存行为

实践经验:

1、关于spring bean注入:充血模型在实体中使用静态注入方法实现。例:

private LabelInfoRepository labelInfoRepository = ApplicationContextUtils.getBean(LabelInfoRepository.class);

2、充血模型的实体序列化,排除非必要属性,在一些redis对象缓存时可能会用到。例:

// 使用注解排除序列化属性
@Getter(AccessLevel.NONE)
private LabelInfoRepository labelInfoRepository = ApplicationContextUtils.getBean(LabelInfoRepository.class);



// 使用注解排除序列化属性
@JSONField(serialize = false)
private ServicePackageConfig servicePackageConfig;
// 使用注解排除序列化 get 方法
@Transient
@JSONField(serialize = false)
public static CooperateServicePackageRepositoryQuery getAllCodeQuery(Long contractId) {    
    CooperateServicePackageRepositoryQuery repositoryQuery = new CooperateServicePackageRepositoryQuery();    
    repositoryQuery.setContractIds(com.google.common.collect.Lists.newArrayList(contractId));    
    repositoryQuery.setCode(RightsPlatformConstants.CODE_ALL);   
     return repositoryQuery;
}

3、利用Set方法建立聚合绑定关系。例:

public void setServiceSkuInfos(List<ServiceSkuInfo> serviceSkuInfos) {    
    if (CollectionUtils.isEmpty(serviceSkuInfos)) 
    {        
        return;    
    }    
    this.serviceSkuInfos = serviceSkuInfos;    
    List<String> allSkuNoSet = serviceSkuInfos
                                .stream()
                                .map(one -> one.getSkuNo())
                                .collect(Collectors.toList());   
     String skuJoinStr = Joiner.on(GlobalConstant.SPLIT_CHAR).join(allSkuNoSet);    
     this.setSkuNoSet(skuJoinStr);}

作者:京东健康 张君毅

来源:京东云开发者社区

与DDD项目落地之充血模型实践相似的内容:

DDD项目落地之充血模型实践

充血模型是DDD分层架构中实体设计的一种方案,可以使关注点聚焦于业务实现,可有效提升开发效率、提升可维护性

大营销抽奖系统,DDD开发要如何建模?

作者:小傅哥 博客:https://bugstack.cn 沉淀、分享、成长,让自己和他人都能有所收获! 大家好,我是技术UP主小傅哥。 ‍ 经过5.1假期的一顿框框输出,终于完成了《大营销项目》第二阶段的开发和上线,体验地址:https://gaga.plus 有了这个项目的落地,

产品代码都给你看了,可别再说不会DDD(七):实体与值对象

这是一个讲解DDD落地的文章系列,作者是《实现领域驱动设计》的译者滕云。本文章系列以一个真实的并已成功上线的软件项目——码如云(https://www.mryqr.com)为例,系统性地讲解DDD在落地实施过程中的各种典型实践,以及在面临实际业务场景时的诸多取舍。 本系列包含以下文章: DDD入门

abp 创建DDD项目

abp 创建DDD项目 我和我的伙伴在搭建框架的基础框架,找了很多框架,最后选择用abp作为DDD的规范标准。 创建项目 1.命令行中安装 ABP CLI: dotnet tool install -g Volo.Abp.Cli 2.查看abp 版本: abp -v 3.如果版本过低,更新版本,目前

【实践篇】DDD脚手架及编码规范

我们团队一直在持续推进业务系统的体系化治理工作,在这个过程中我们沉淀了自己的DDD脚手架项目。本文主要是梳理和总结了DDD脚手架使用中的编码规范以及遇到的问题。

一个.NET 7 + DDD + CQRS +React+Vite的实战项目

## 项目简介 基于SignalR实现聊天通信,支持横向扩展,可支撑上万用户同时在线聊天 ## 快速体验 http://server.tokengo.top:8888/ 可在这里快速体验使用,请注意目前只适配了PC端,请勿使用手机访问,可能出现样式不适应的情况, 当然如果你想要自己部署也可以,目前提

无业游民写的最后一个.net有关项目框架

理想很丰满,现实往往很残酷。 一种按照ddd的方式,根据业务来把自己需要的模块一个一个写出来,再按照模块把需要的接口一个一个的写出来,堆砌一些中间件,以及解耦的command,handler等等 ,一个项目就这么成型了。上面的项目有一个非常清晰的特点,就是按需开发,不需要去可以定义业务相关的公共的模

火山引擎A/B测试平台的实验管理重构与DDD实践

本次分享的主题是火山引擎数智平台VeDI旗下的A/B测试平台 DataTester 实验管理架构升级与DDD实践。这里说明的一点是,代码的第一目标肯定是满足产品需求,能够满足产品需求的代码都是好代码。而本文中对代码的好坏的评价完全是从架构的视角,结合代码的可读性、可维护性与可扩展性去分析的。 在一个

关于DDD和COLA的一些总结和思考

写在前面: 其实之前一直想汇总一篇关于自己对于面向对象的思考以及实践的文章,但是苦于自己的“墨迹”,一延再延,最近机缘巧合下仔细了解了一下COLA的内容,这个想法再次被勾起,所以这次一鼓作气,准备好好梳理一篇。至于标题,因为是被DDD和COLA唤起的,索性就叫这个吧。 思维:面向对象和面向过程 领域

DDD架构为什么应该首选六边形架构?

采用依赖倒置原则后的分层架构和六边形架构,实际上都符合整洁架构设计理念。但是六边形架构中使用端口与适配器,让应用程序能够以一致的方式被用户、程序、自动化测试、批处理脚本所驱动,同时能够让应用程序边界更加清晰,从而能更好地防止领域层和应用层逻辑泄露到外层。