新项目从零到一DDD实战思考与总结

原创 吴就业 186 0 2021-06-30

本文为博主原创文章,未经博主允许不得转载。

本文链接:https://wujiuye.com/article/0adc01dad9c8462ab29d24837f3947a9

作者:吴就业
链接:https://wujiuye.com/article/0adc01dad9c8462ab29d24837f3947a9
来源:吴就业的网络日记
本文为博主原创文章,未经博主允许不得转载。

本篇文章写于2021年06月30日,从公众号|掘金|CSDN手工同步过来(博客搬家),本篇为原创文章。

领域驱动设计(DDD)是一种业务领域建模方法论、业务架构设计方法论,战略设计阶段从业务领域视角划分领域边界,抽象业务建立领域模型;战术设计阶段则根据清晰的领域边界、领域模型进行架构设计与开发实现。

DDD解决了核心复杂业务设计问题,简化业务系统的实现,让业务逻辑高度内聚,与基础设施、框架解耦,清晰的领域边界解决微服务的拆分问题。聚合之间通过聚合根ID引用与领域事件松耦合,保持高内聚、松耦合让项目代码随着业务需求的不断迭代保持整洁。

本篇笔者以近期的一个项目实战跟大家分享笔者目前对DDD的理解,以及在实战DDD过程中遇到的问题思考与总结,仅个人经验,偏战术设计。

从项目实战中理解DDD核心概念

领域通常指的就是业务范围,每个公司都有自己明确的业务范围。通常每个公司内部都有很多个系统,如一家电商公司可能会有物流系统、电商系统、直播系统等等,每个系统做的事情则是更细分的领域。

茉莉红交所(红探长)项目是笔者入职茉莉数科集团后做的第一个项目,也是一个新的项目,由于没有历史包袱,笔者从零开始搭建整个项目,因此选择在该项目试行DDD。

该项目业务是OTO(线上到线下)探店,OTO探店就是该项目的领域。

探店其实是一种商家线上付费下单、平台为商家匹配达人、达人线下探店线上内容推广的内容营销模式,可以是品尝美食或是免门票游玩景点等,达人最终通过短视频、直播、图文内容等方式为商家做推广。那么无论是探美食店、探游乐园,探店都是这个领域的核心。

在探店这个领域中,核心的业务名词有:商家、达人、店铺、订单、任务,而核心事件有:店铺入驻、商家发布订单、达人接单等。

附上此项目对应版本的架构设计图:

image.png

提示:中间部分不是每个限界上下文对应一个微服务,可以是多个限界上下文合并在一个微服务。

限界上下文是业务概念的边界,是业务问题最小粒度的划分。在OTO探店业务领域中会包含多个限界上下文,我们通过找出这些确定的限界上下文对系统进行解耦,要求每一个限界上下文其内部必须是紧密组织的、职责明确的、具有较高的内聚性。

我们划分出的限界上下文如下图所示。

截屏2021-05-05 15.14.01.png

提示:为什么将任务和订单拆分为不同限界上下文(*任务不是作为订单聚合根的实体,而是作为一个独立聚合的聚合根*)?这是因为商家发布的一个订单允许有不同的多个达人接单,一个达人也可以接不同商家的订单,这并不是简单的一对多关系。这更像是商品与订单的关系,而不是订单与订单item的关系。

在划分出限界上下文后,还需要根据限界上下文识别出问题子域。问题子域是对业务问题的划分,相对限界上下文来说,是对业务问题更大粒度的划分。

根据限界上下文,我们划分出的子域如下图所示。

截屏2021-05-09 15.05.00.png

在划分出子域后,我们需要为领域建模。

领域建模是通过将业务抽象为聚合、实体、聚合根、值对象模型的方式,封装和承载全部的业务逻辑,保持业务的高内聚和低耦合。

70%的场景下,一个聚合内都只有一个实体,那就是聚合根。

在技术实现上,一个聚合就是一个包,里面存放领域服务、工厂、资源库、聚合根、实体、值对象

领域层包的划分规则通常为:

----限界上下文
--domain
------聚合A
-------- (聚合根、实体、值对象、领域服务、资源库、领域事件)
------聚合B
-------- (聚合根、实体、值对象、领域服务、资源库、领域事件)

特别的,一个限界上下文可能包含多个聚合,但一个聚合只能存在于一个限界上下文。

以上包的划分只是领域层的划分,要求聚合根、实体、值对象、领域服务、资源库、领域事件等类存放在聚合包下,无论是使用DDD经典四层架构,还是六边形架构。

以店铺上下文为例,我们采样六边形架构实现,整个模块的层次、包划分如下:

com.mmg.hjs.storecontext(限界上下文)
--adapters(适配层)
----api(API接口适配)
------webmvc(前端接口,请求从网关进来)
------dubbo(内部微服务调用,实现应用层gateway包下的接口)
----persistence(持久化适配)
------dao(mybatis的Mapper类与xml文件)
------po(对应数据库表生成的类)
------StoreAssembler.class(领域实体转PO的转换器)
------StoreRepositoryImpl.class(实现领域层的资源库接口)
----cache(缓存适配)
--application(应用层)
----gateway(与其它限界上下文通信并与适配层接耦的抽象接口)
----job(可选,定时任务)
----representation(应用服务,处理只写)
----usecase(应用服务,按用例拆分多个类,避免单个类臃肿)
----assembler(聚合根转DTO转换器)
----dto(DTO类)
----cqe(CQE模式)
------command(请求参数)
------query(查询参数)
------event(可选,事件参数,注意:非领域事件)
--domain(领域层)
----store(店铺聚合)
------model(聚合根、实体、值对象)
------event(领域事件)
------StoreDomainService.class(领域服务)
------StoreRepository.class(资源库抽象接口)

在分层架构模式中,我们需要严格遵循:上层只能依赖下层,下层不能依赖上层。

例如,在一次创建订单的操作中,用于接收前端请求参数的CreateOrderCommand属于应用层的类,虽然我们在Controller(接口层)可直接使用CreateOrderCommand,但这属于上层依赖下层,并且不是领域层,也并未暴露聚合根内部结构,因此是允许的。

如果反过来,直接将CreateOrderCommand对象传递给聚合根,那就构成下层依赖上层了,因此这是不允许的。CreateOrderCommand必须在应用层拆解为创建订单所需要的值对象,或者实体对象,再调用领域服务方法,领域服务方法调用订单工厂创建订单,最后才交给资源库持久化订单聚合根。

在领域层里面,更准确的说是在聚合包内,存储的是聚合下的聚合根、实体、值对象、资源库、领域服务、聚合根工厂类,而由于资源库的实现需要依赖orm框架或其它框架实现持久化聚合根、事件的发布需要依赖MQ实现等,所以资源库定义成接口由上层实现,事件发布也定义为接口由上层实现。

对于资源库与事件发布者,由于领域服务需要依赖资源库获取和保存聚合根,也依赖事件发布者发布事件,这种情况下我们可以使用Spring框架的自动注入,但应该使用构造函数注入,而不是在字段上加注解的方式注入,避免注入资源库、事件发布者为NULL的情况,且不应该添加Spring框架的注解(尽量不耦合)。

应用服务、领域服务、聚合根、资源库的职责

在实现DDD的过程中,我们需要严格遵守代码规范才能保持代码的整洁,否则随着需求的迭代,项目很容易就失去DDD该有的模样,变得即不DDD也不MVC。

在DDD中,Repository(资源库)是聚合根的容器,与DAO扮演相同角色,但它只提供持久化聚合根的操作(新增或更新),以及提供根据ID获取聚合根的查询操作。在所有的领域对象中,只有聚合根才拥有Repository,因为Repository不同于DAO,它所扮演的角色只是向领域模型提供聚合根。

资源库(Repository) 的职责是提供聚合根或者持久化聚合根,除此之外应「尽可能」的没有其它行为,否则聚合根就会严重退化成DAO。

public interface Repository<DO, KEY> {
    void save(DO obj);
    DO findById(KEY id);
    void deleteById(KEY id);
}

聚合根领域服务(DomainService) 负则封装实现业务逻辑,应用服务(ApplicationService) 不处理业务逻辑,而只是对领域服务/聚合根方法调用的封装。

正常情况下,处理一次业务请求将经过:

应用服务->领域服务->通过资源库获取聚合根
        ->通过资源库持久化聚合根
        ->发布领域事件

但也允许:

应用服务->通过资源库获取聚合根
       ->通过资源库持久化聚合根
       ->发布领域事件

对于不能直接通过聚合根完成的业务操作就需要通过领域服务。

但必须遵守原则:

聚合根工厂负责创建聚合根,但并非必须的,只需要将聚合根的创建写到聚合根下并改为静态方法,非常复杂的创建过程才建议写工厂类。

以修改用户信息为例,可在应用服务通过资源库获取用户聚合根,再调用用户聚合根的修改用户信息方法,最后通过资源库持久化用户聚合根。

public class UserModifyInfoUseCase{

    /**
     * 更新用户基本信息
     *
     * @param command
     * @param token
     */
    @Transactional(rollbackFor = Throwable.class, isolation = Isolation.READ_COMMITTED)
    public void updateUserInfo(ModifyUserInfoCommand command, Long loginUserId) {
        // 获取聚合根
        Account account = findByAccountId(loginUserId);
        // 调用业务方法
        account.modifyAccountInfo(AccountInfoValobj.builder()
                .nickname(command.getNickname())
                .avatarUrl(command.getAvatarUrl())
                .country(command.getCountry())
                .province(command.getProvince())
                .city(command.getCity())
                .gender(Sex.valueBy(command.getGender()))
                .build());
        // 通过资源库持久化
        repository.save(account);
        // 更新缓存
        accountCache.cache(loginUserId, getUserById(account.getId()));
    }

}

这里用户聚合根能到看到自己的信息,用户自己修改自己的信息可直接通过聚合根完成,因此这种场景下我们不需要领域服务。

复杂场景如用户绑定手机号码就不能直接在领域服务中完成。

绑定手机号码一般流程为:获取短信验证码、校验短信验证码、校验手机号码是否已经绑定了别的账号。

其中获取短信验证码与校验短信验证码应放在应用服务完成,而校验手机号码是否已经绑定了别的账号就需要由领域服务完成,因为聚合根无法完成这个判断, 聚合根看不到别的账号,聚合根不能拥有资源库,且应用服务不能处理业务逻辑。

聚合根

public class Account extends BaseAggregate<AccountEvent>{
    // .....
    private String phone;

    public void bindMobilePhone(String phoneNumber) {
        if (!StringUtils.isEmpty(this.phone)) {
            throw new AccountParamException("已经绑定过手机号码了,如需更新可走更换手机号码流程");
        }
        this.phone = phoneNumber;
    }

}

领域服务

@Service
public class AccountDomainService {
    
    private AccountRepository repository;

    public AccountDomainService(AccountRepository repository) {
        this.repository = repository;
    }

    public void bindMobilePhone(Long userId, String phone) {
        Account account = repository.findById(userId);
        if (account == null) {
            throw new AccountNotFoundException(userId);
        }
        // 号码被其它账户绑定了
        boolean exist = repository.findByPhone(phone) != null;
        if (exist) {
            throw new AccountBindPhoneException(phone);
        }
        account.bindMobilePhone(phone);
        repository.save(account);
    }

}

应用服务

@Service
public class UserBindPhoneUseCase {
    
       /**
         * 绑定手机号码-发送验证码
         *
         * @param command
         * @param token
         */
        public void bindMobilePhoneSendVerifyCode(VerifyCodeSendCommand command, Long loginUserId) {
            // 生成验证码
            String verifyCode = ValidCodeUtils.generateNumberValidCode(4);
            // 缓存验证码
            verifyCodeCache.save(command.getPhone(),verifyCode,timeout);
            // 调用消息服务发送验证码
            messageClientGateway.sendSmsVerifyCode(command.getPhone(), verifyCode);
        }
    
        /**
         * 绑定手机号码-提交绑定
         *
         * @param command
         * @param token
         */
        public void bindMobilePhone(BindPhoneCommand command, Long userId) {
            // 校验验证码
            String verifyCode = verifyCodeCache.get(command.getPhone());
            if (!command.getVerifyCode().equalsIgnoreCase(verifyCode)) {
                throw new VerifyPhoneCodeApplicationException();
            }
            // 通过领域服务绑定手机号码
            accountDomainService.bindMobilePhone(userId, command.getPhone());
            // 更新账号缓存
            accountCache.cache(userId, getUserById(userId));
        }
}

接口层

@RestController
@RequestMapping("account/bindMobilePhone")
public class UserBindPhoneController {
 
    @Resource
    private UserBindPhoneUseCase useCase;

    @ApiOperation("绑定手机号-获取验证码")
    @GetMapping("/verifyCode")
    public Response<Void> bindMobilePhone(@RequestParam("phone") String phone) {
        Long userId = WebUtils.getLoginUserId();
        useCase.bindMobilePhoneSendVerifyCode(phone, userId);
        return Response.success();
    }

    @ApiOperation("绑定手机号-提交绑定")
    @PostMapping("/submit")
    public Response<Void> bindMobilePhone(@RequestBody @Validated BindPhoneCommand command) {
        Long userId = WebUtils.getLoginUserId();
        useCase.bindMobilePhone(command, userId);
        return Response.success();
    }
    
}

CQE模式

CQE即Command、Query、Event。接收前端创建订单请求使用Command,接收前端分页查询请求使用Query,消费事件(非领域事件)则使用Event。

除Event外,所有写请求都应该使用Command接收参数,而所有查询都应该使用Query接收参数,只在参数只有一个ID的查询情况下,可省略Query。

在查询分离情况下,Query是可直接传递到DAO的(接口层->应用层->DAO)。因此使用Query封装查询条件能够提高方法的复用,当添加查询条件时,无需给方法加多一个参数。

CQRS模式

CQRS(Command Query Resposibility Segregation),即命令查询职责分离模式。软件模型中存在读模型和写模型之分,以我们写业务代码的经验也知道,一次请求,要么是作为一个“命令”执行一次操作,要么作为一个”查询“向调用方返回数据,两者不可能共存。CQRS是将“命令”和“查询”分别使用不同的对象模型来表示。

CQRS的读操作放在应用层。

共享存储-共享模型-CQRS

共享存储指同一个表结构存储数据,共享模型指使用聚合根从数据库读取数据。

例如查询订单详情,订单的聚合根为Order。

// 订单聚合根
public class Order extends BaseAggregate {
}

在应用层OrderDetailsUseCase通过OrderRepository查询订单聚合根,再调用装配器将聚合根转为读模型。

public class OrderDetailsUseCase {
    public OrderDto byId(String id) {
        Order order = orderRepository.byId(id);
        return orderDaoAssembler.toDto(order);
    }
}

注意:读操作和写操作不要写在同一个应用服务中,避免耦合,且应用服务应按用例拆分多个类,避免应用服务越写越臃肿。

共享存储-读写分离模型-CQRS

共享存储-读写分离模型指读写还是操作同一张表,只是写模型与读模型不同,写通过聚合根操作,而读模型绕过聚合根、Repository,直接操作数据库,此时的读模型就是用于装载从数据库查询的数据,并且不需要再作转换就可以响应给调用方,这里的读模型就是DTO。

对于单个聚合根内的查询,使用「共享存储-读写分离模型」模型可以应付复杂的查询场景,并且可以提升性能。

对于需要跨多个聚合根的查询,「共享存储-共享模型」无法实现此需求场景,而分别查询多个聚合根后,再合并查询结果不仅是将原本简单的事情变复杂,还大大影响性能,因此更有必要采用「共享存储-读写分离模型」。

对于查询订单详情希望带上商品信息,如果商品与订单在同一个服务,并且同一个数据库,那么便可以使用join多表查询。

共享存储-读写分离模型-CQRS实战举例:

接口层

@RequestMapping("/order")
@RestController
public class OrderQueryController {
    
    @GetMapping("/query")
    public Response<PageInfo<OrderQueryDto>> queryOrder(OrderQuery query) {
        return Response.success(orderQueryUseCase.queryOrder(query,WebUtils.getLoginUserId()));
    }

}

应用层

@Service
public class OrderQueryUseCase implements Cqrs {

    public PageInfo<OrderQueryDto> queryOrder(OrderQuery query, Long loginUserId) {
        Long merchantId = merchantGateway.getMerchantId(loginUserId);
        IPage<OrderQueryDto> orderPage = new Page<>(query.getPage(), query.getPageSize());
        List<OrderQueryDto> orders = orderMapper.selectOrderBy(merchantId,query,orderPage);
        PageInfo<OrderQueryDto> pageInfo = new PageInfo<>(page, pageSize);
        pageInfo.setTotalCount((int) orderPage.getTotal());
        pageInfo.setList(orders);
        return pageInfo;
    }
}

读写分离存储-读写分离模型

即读与写操作不同数据库。例如,对于查询订单详情希望带上商品信息,如果商品是一个微服务、订单是一个微服务,并且两个微服务使用不同的数据库,如果要提升性能,就需要通过额外的数据同步服务,将订单与商品查询结果合并后存入一个新的表(分离存储)或者是存储到NoSQL数据库。数据同步可通过底层数据库Binlog+Kafka消费实现,还有一种是通过消费领域事件实现,但影响应用性能。

提示:对于复杂的报表统计,建议通过Binlog+Kafka同步到一张大表,为不与业务耦合,应独立为一个数据服务。

领域事件的发布

在DDD中有一个原则,一个业务用例对应一个事务,一个事务对应一个聚合根,即在一次事务中只能对一个聚合根操作。

但在实际应用中,一个业务用例往往需要修改多个聚合根,而不同的聚合根可能在不同的限界上下文中,引入领域事件即不破坏DDD的一个事务只修改一个聚合根的原则,也能实现限界上下文之间的解耦。

在DDD中,领域层是业务逻辑的具体实现,所有以解决问题子域的业务代码都高度内聚在限界上下文中、高度内聚在聚合中,即聚合根、实体以及领域服务内。

对于领域事件发布,我们的实现是在聚合根中临时保存,最后在领域服务/应用服务发布,领域层抽象事件发布接口,由适配器层实现,并注入到领域服务/应用服务。

一个原因是领域层不应该依赖其它框架的Api,另一个原因则与领域事件是由聚合根/领域服务创建有关。

那为什么领域事件由聚合根/领域服务创建,而不是在应用层创建?

发布领域事件当然是在领域层发出,可以是聚合根发出,也可以在领域服务发出,业务在聚合下高度内聚,什么时候该发出什么事件也只有聚合内最清楚,应用服务不过是封装业务实现的步骤。

由于业务逻辑最核心的实现是聚合根内,而聚合根是一个实体,不能说每次构造聚合根都传入一个事件发布者,那从资源库获取聚合根时又由谁传入事件发布者?

所以推荐的做法是在聚合根下临时存储聚合根发出的事件,在领域服务中、在调用资源库持久化聚合根之后再发布领域事件。当然,在不使用领域服务的情况下,则由应用层在调用资源库持久化聚合根之后再发布领域事件。

应用服务一个业务用例只是对应领域服务方法的一层很薄的封装,即不会在一个应用服务方法中调用两个领域服务方法。这实际上也是我们要注意,如果出现这种情况,说明领域服务方法封装的不够好。所以领域事件由领域服务发布是允许的,但事件发布者必须抽象为接口,与资源库一样在领域服务的构建方法传入。

关于我们为什么先通过Spring框架发布事件再在订阅者中实现将事件发布到MQ。

一个事件可能当前限界上下文内也需要消费,即可能有多个限界上下文需要消费,一个事件对应多个消费者。

如订单限界上下文内订单聚合产生的创建订单事件,订单限界上下文内需要消费订单创建事件,用于构造消息通知,然后给消息通知队列写入消息;同时,其它限界上下文也需要消费订单创建事件。因此,一个领域事件我们可能需要发布到多个消息对接中。

先通过Spring框架发布事件再在订阅者中实现将事件发布到MQ其实是借助Spring框架实现责任链模式。这当然不是必须的,也算不上是规范。

但不管如何,不要直接在领域服务/应用服务中调用MQ的API直接发布事件,发布事件到MQ应在适配层实现。并且封装事件发布者的好处在于,当需要确保消息至少投递一次时,这些逻辑不需要写在应用服务中。

最令人头疼的代码

在实战DDD的过程中,我们编写最多的代码无疑就是DO(聚合根)转DTO(读模型)以及DO转PO(映射到数据库表)和PO转DO的转换器代码。百分之八十的BUG都来自这些整齐划一的属性拷贝代码,容易漏字段。

那为什么需要这么多层转换呢,直接将聚合根响应给请求、直接持久化聚合根不行吗?

首先,在DDD中我们必须先获取到聚合根再通过聚合根完成业务逻辑,最终通过资源库持久化聚合根。

为什么需要将DO转PO,这是必须要做的事情吗?

如果我们选择关系型数据库持久化聚合根,那么就可能需要将聚合根拆分存储到多个表,并且对于枚举类型我们也需要转成数值类型再存储。基于这些场景就需要将聚合根转为PO再调用对应表的DAO存储到数据库中。

为什么需要将DO转DTO?

除了我们必须要遵守不暴露聚合根内部结构给外部之外,前端需要的数据也是不一样的,比如我们需要将枚举类型字段拆成值和名称两个字段,以及需要屏蔽一些字段。

为了不暴露聚合根内部结构,聚合根应只暴露GET方法,用于外部获取字段值,同时使用Builder模式提供builder方法给资源库(使用装配器)将PO转为聚合根。对于实体也可以这样做,而值对象只提供所有参数的构造方法和GET方法。当然了,使用哪种做法都没有错。

对于通用的转换操作我们为每个聚合根提供一个实现将DO(聚合根)转为DTO的装配器(转换器)、以及一个实现PO和DO相互转换的装配器(转换器)。

基于这种实现,笔者也寻找过能够解决这些繁琐操作提升工作效率的方法,我们试过用mapstruct框架,但mapstruct也只适用于简单的聚合根,对于复杂内部结构的聚合根映射也需要写一堆注解,工作量没有减少反而增加了问题排查的难度。使用Spring提供的属性拷贝工作类也是一样的,无法解决问题。

优化聚合根的持久化性能

对于使用关系型数据库持久化聚合根的场景,在“只能通过Repository的save方法持久化聚合根”这个约束下,save方法在性能上是有非常大的损耗的,因为更新一个聚合根需要同时更新聚合根下的实体。为了降低性能影响,可在更新之前对比一下内存中的快照,只对有更新的实体执行更新操作,笔者单独写了一篇文章介绍如何实现:《DDD资源库Repository的性能优化》

如今分布式数据库已经成熟,不建议在新项目中引入分库分表ORM框架以及分布式事务框架,更不建议使用分库分表,这些应该交由底层数据库完成,或增加一层代理完成。

总结

因为DDD缺少权威性的实践指导和代码约束,我们只能是通过实践慢慢积累经验。个人的理解也并非完全正确的,对于限界上下文的划分,我们只是凭经验划分,但又缺少经验,新业务也处于不断摸索状态,现在的限界上下文划分、建模不代表将来不会推倒重来。

参考文献


PS: 很多人找我要代码,几年前的代码了,也不是不能给,但我这个人不喜欢被白嫖代码。付费资源,有需要可以下载,嫌要钱可以忽略,没有人强迫哈!https://www.wujiuye.com/resource/050c6941835641fc908f0f8a7de44c2b

#后端

声明:公众号、CSDN、掘金的曾用名:“Java艺术”,因此您可能看到一些早期的文章的图片有“Java艺术”的水印。

文章推荐

Go项目如何远程调试

远程debug也是排查线上故障的有效手段。容器下受权限限制,需要以root启动进程,并且获得特权模式才可使用。

Java中的中断机制

中断,其实只是jvm用于唤醒因锁竞争、I/O操作、休眠等待被挂起的线程,并设置一个中断标志,我们可以利用这个标志去做一些处理。

https证书如何验证是否生效

在做接入器中间件需求时,接入器需要支持cdn通过https协议回源,测试怎么验证证书有没有生效呢?

如何将项目打包部署到私有仓库(Nexus)

公司项目使用的是maven,并且不是推送到maven中央仓库,而是推送到私有仓库nexus,本篇将介绍如何将sdk项目打包部署到私有仓库。

写业务系统,更重要的是设计

写业务系统,我们应该更注重设计,好的设计能解决百分之八十的问题。

Spring Native与WebFlux一样注定昙花一现?

从Spring Native官方文档来看,我是承认它的优秀的,我也会继续关注它,或许将来在合适的项目中去使用它,至少从目前的了解来看,我还不会只为性能买单,一是对现有项目的改造成本略高,二是出于目前项目的成熟度考虑我们还缺少一些云原生组件的支持。