业务代码编程陷阱案例 - jaxenter


当我们开始编写软件时,我们总是希望有一个好的设计。我们阅读书籍,运用最佳实践,最后,我们常常一团糟。根据我在一家定制软件开发公司的经验,我每天必须处理此类代码,尤其是在某些旧系统上工作时。
造成这种情况的原因多种多样,我将尝试在一系列文章中以一些实际的方式来探讨其中的一些原因。在我的第一个示例中,我将说明为什么简单的软件会演变成一场噩梦,并建议进行一些改进。我将只专注于处理业务逻辑的服务层。
让我们从一个简单的存储应用程序开始。我们拥有带有服务,存储库的产品资源,并且我们可以执行我们认为需要的CRUD操作。我们的产品服务如下所示:

public class ProductService {
    public String create(Product product) {
        return productRepository.create(product);
    }
    public String update(Product product) {
        return productRepository.update(product);
    }
    public Product get(String productId) {
        return productRepository.get(productId);
    }
    public void delete(Product product) {
        productRepository.delete(product);
    }
}

还会有其他一些东西,例如DTO到实体的映射,控制器等。但是正如我所说的,我们将考虑将它们编写为简化起见。我们的产品实体是简单的Java Bean,我们的存储库保存在正确的数据库表中。然后,我们得到另一个要求,即我们还将创建一个在线商店,并且需要一种下订单的方法。因此,我们添加了快速订购服务来满足我们仍然很简单的要求:

 public class OrderService {
    public String saveOrder(Order order) {
        return orderRepository.save(order);
    }
}

它简单,易读且有效!然后,下订单时就需要更新库存中的产品的新要求。我们这样做:

public class OrderService {
    public String saveOrder(Order order) {
        Product product=productService.get(order.getProductId());
        product.setAvailableQuantity(product.getAvailableQuantity()-order.getQuantity());
        productService.update(product);
        
        return orderRepository.save(order);
    }
}

我们又碰到三个新需求:

  • 我们需要致电运输服务将该产品运送到一个地址
  • 如果没有足够的库存来履行订单,则抛出一个错误
  • 如果产品的可用数量低于最低数量以进行重新库存。

结果如下:

public class OrderService {
    public String saveOrder(Order order) {
        Product product=productService.get(order.getProductId());
        
        //The order service works more like a product service in the following liness
        if(product.getAvailableQuantity()<order.getQuantity()){
            throw new ProductNotAvailableException();
        }
        product.setAvailableQuantity(product.getAvailableQuantity()-order.getQuantity());
        productService.update(product);
        if(product.getAvailableQuantity()<Product.MINIMUM_STOCK_QUANTITY){
            productService.restock(product);
        }
        
        //It also needs to know how shipments are created
        Shipment shipment=new Shipment(product, order.getQuantity(), order.getAddressTo());
        shipmentService.save(shipment);
        
        return orderRepository.save(order);
    }
}

我知道这可能是一个极端的例子,但是我确信我们在项目中已经看到了类似的代码。这样做有多个问题–责任z职责共担,与其他领域的逻辑和基础架构混淆在以前等等。如果这是一个真实的商店,那么接单的人就像总经理–照顾一切,从实际订购库存维护和交付。

更好的版本
让我们尝试以不同的方式处理相同的情况。我将从订购服务开始。为什么我们调用方法saveOrder?因为我们将其视为开发人员,而不是从业务角度来看。我们开发人员的想法通常是数据库驱动的(或REST驱动的),我们将我们的软件视为一系列CRUD操作。通常,当我们阅读有关领域驱动设计的书籍时,会提到通用语言-开发人员和用户之间的通用语言。如果我们尝试在我们的代码中为业务建模,那么为什么不使用正确的术语。我们可以将初始代码更改为:

public class OrderService {
    public String placeOrder(Order order) {
        return orderRepository.save(order);
    }
}

使用placeOrder替代了原理的saveOrder方法名。
进行很小的更改,但即使那样也会使其更具可读性。这是业务层,而不是数据库层–我们去商店时下订单place order,但不保存订单save order。然后,当其他需求出现时,而不是开始使用带有CRUD操作的现有服务来编码它们,我们可以尝试重新创建业务模型。我们询问业务人员,他们告诉我们,下订单时,接单的人员会致电库存部门,询问他们产品是否可用,然后进行储备并致电带有预定编号和地址的交货人员,以便他们装运它。是什么阻止我们在代码中执行相同的操作?

public class OrderService {
    public String placeOrder(Order order) {
        String productReservationId=productService.requestProductReservation(order.getProductId, order.getQuantity());
        String shippingId=shipmentService.requestDelivery(productReservationId, order.getAddressTo());
        order.addShippingId(shippingId);
        return orderRepository.save(order);
    }
}

在我看来,它看起来更加干净,代表了实际商店中发生的事件的顺序。订单服务不需要知道产品如何工作或运输如何工作。它只是使用完成工作所需的方法。我们也需要修改其他服务:

public class ProductService {
    //Method used in Orders Service
    public String requestProductReservation(String productId, int quantity){
        Product product=productRepository.get(productId);
        product.reserve(quantity);
        productRepository.update(product);
        return createProductReservation(product, quantity);
    }
    
    private String createProductReservation(Product product, int quantity){
        ProductReservation reservation=new ProductReservation(product,quantity);
        reservation.setStatus(ReservationStatus.CREATED);
        return reservationRepository.save(reservation);
    }
    
    //Method used in Shipment Service
    public ProductReservation getProductsForDelivery(String reservationId){
        ProductReservation reservation=reservationRepository.getProductReservation(reservationId);
        reservation.getProduct.releaseReserved(reservation.getQuantity());
        if(reservation.getProduct().needRestock()){
            this.restock(product);
        }
        reservation.setStatus(ReservationStatus.PROCESSED);
        reservationRepository.update(reservation);
    }
}

产品服务提供了其他服务要使用的两种方法,但对它们的结构一无所知。它不关心订单,发货等。当产品需要补货以及产品数量是否足够时,逻辑就在实际产品内部。

public class Product() {
    //Fields, getters, setters etc...
    
    public void reserve(int quantity){
        if(this.availableQuantity - this.reservedQuantity > quantity){
            this.reservedQuantity+=quantity;
        } else
            throw new ProductReservationException();
    }
    public releaseReserved(int requested){
        if(this.reservedQuantity>=requested){
            this.reservedQuantity-=requested;
            this.availableQuantity-=requested;
        } else 
            throw new ProductReservationException();
    }
    public boolean needsRestock(){
        return this.availableQuantity<MINIMUM_STOCK_QUANTITY;
    }
}

装货服务:

public class ShipmentService {
    public String requestDelivery(String reservationId, Address address){
        ProductReservation reservation=productService.getProductForDelivery(reservationId);
        Shipment shipment=new Shipment(reservation, address);
        return shipmentRepository.save(shipment);
    }
}

我并不是说这是最好的设计,但我认为它要干净得多。每个服务都照顾自己的领域,并且对其他服务了解得最少。实际的实体不仅是数据持有者,而且还携带与之相关的逻辑,因此服务不需要直接修改其内部状态。在我看来,最有价值的是代码真正代表了业务运作方式。
 

不错的示例,是典型的CRUD到DDD过渡中使用用的方式,对传统开发思维的过渡曲线不会太陡,可行性较高,但如果使用贫血domain,容易造成各个service方法膨胀。

我们原来用的方法是没有service, 直接用OrderHandler(PlaceOrderCommand), 然后在Handler中调用domain方法 Order.AssignShip(),这样,业务集中在domain中,application层(controller)就比较薄,只需要负责装配。

good