业务代码编程陷阱案例(领域驱动设计)

当我们开始编写软件时，我们总是希望有一个好的设计。我们阅读书籍，运用最佳实践，最后，我们常常一团糟。根据我在一家定制软件开发公司的经验，我每天必须处理此类代码，尤其是在某些旧系统上工作时。

造成这种情况的原因多种多样，我将尝试在一系列文章中以一些实际的方式来探讨其中的一些原因。在我的第一个示例中，我将说明为什么简单的软件会演变成一场噩梦，并建议进行一些改进。我将只专注于处理业务逻辑的服务层。

让我们从一个简单的存储应用程序开始。我们拥有带有服务，存储库的产品资源，并且我们可以执行我们认为需要的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操作。我们的产品服务如下所示：

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