领域驱动设计(DDD):如何使用DDD的思想优化你的代码

轻舟技术A

已于 2023-08-21 23:18:48 修改

阅读量340

点赞数 1

CC 4.0 BY-SA版权

分类专栏： DDD 文章标签： java 架构

于 2023-08-19 12:20:26 首次发布

本文链接：https://blog.youkuaiyun.com/fuwei2020/article/details/132378539

大家好，我是付威，一名奋斗在代码第一线十余年的程序员。在2019年我初次接触到领域驱动设计（Domain-Driven Design，简称DDD）的概念。在我的探索中，我发现许多有关DDD的教程过于偏重于战略设计，充斥着许多晦涩难懂的概念，导致阅读起来相当艰难。有些教程往往只是解释了DDD的概念，而未深入探讨为何要采用这种方式以及这样做能带来哪些好处，这导致很多人在实践应用DDD时遇到了诸多难题。甚至有些人为了引入DDD而在项目中强制采用DDD架构，结果却意外增加了代码的复杂性，带来了一系列潜在的风险。

为了解决这一问题，我计划从代码的基础入手，详细讲解如何将DDD的理念应用于实际开发中，以便解答为何DDD能使我们的代码更加整洁的问题。今天，我们将着重讨论如何运用DDD的思想来组织我们的代码，从而实现"高内聚、低耦合"的开发目标。

首先，让我们看一个电商系统中下单功能的代码示例：

@Autowired
ProductDao productDao;
@Autowired
UserDao userDao;
public void createOrder(String productId,String userId,int count){
   
     Product product = productDao.queryById(productId);
     UserInfo user=userDao.queryByUserId(userId);
     
     //风控检测
     RiskResponse riskRes= riskClient.queryRisk(xxx);
     if(riskRes!=null&&riskRes.getCode()==0&&riskRes.getRiskCode().equal("0001")){
   
       //命中风控
          throw new BizException("下单失败，请检查网络")
     }
  
     Order order=new Order();
     order.setOrderId(IdUtils.generateId());
     order.setPrice(product.getPrice()*count);
     order.setAddress(user.getAddress());
     order.setStatus(OrderEnum.OrderSucess);
     orderDao.insert(order);
  
     //预热缓存和增加记录
     redisService.set("Order:OrderID_"+order.getOrderId(),order);
     orderLogDao.addLog(order);
       
      MessageEntity message = new MessageEntity();
      message.setOrderId(order.getOrderId());
      message.setMessage("下单成功");
      kafkaSender.sent(messageEntity);

}

代码分析

首先，我们对这段代码的逻辑进行整理，共涉及5个步骤：

查询商品和用户信息
下单行为的风控检测
订单创建和持久化
写入缓存和记录下单日志
发送订单下单成功消息，通知其他系统

我们从这几个过程入手，根据业务的重要性，我们可以将它们划分为核心业务和非核心业务。显然，下单及其相关操作属于核心代码（步骤1、2、3）。与此相比，写日志、写入缓存以及发送Kafka消息则属于下单过程的非核心业务

核心代码分析

1. 【查询商品和用户信息】

productDao 和 userDao 这两个类是用于封装数据库的增删改查（CRUD）操作。然而，这种封装方式的问题在于，它们的方法实现与具体的数据存储介质密切相关，导致我们的业务逻辑对数据存储方式有着强烈的依赖。

举个例子来说明：当前情况下，我们的数据存储介质是MySQL数据库，因此 userDao 和 productDao 类中的方法都是基于SQL语句的封装。然而，如果以后需要更换不同的数据访问框架，或者将数据存储从MySQL迁移到Elasticsearch（ES），我们就必须修改 userDao 和 productDao 类的实现，以适应新的数据存储方式。这样的操作不仅会对核心业务代码产生影响，还会在项目的各个角落引发不确定性，从而导致每一次的代码优化都需要小心谨慎地进行。

这种紧密耦合的情况，除了增加了代码维护的难度，还可能引发系统的脆弱性。一旦需要改动存储