设计应用程序业务层时的陷阱

即使是最简单的软件，有时也可能陷入意大利面条式的代码中，成为浏览的噩梦，尤其是在旧系统中。在本文中，从应用程序的业务层查看一些错误的代码，以及如何使用更好的设计实践对其进行修复。在这些小小的改进无法处理之前，请注意噩梦代码。

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

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

首先，我们实际上经常看到（和编写）一些错误的代码

让我们从一个简单的存储应用程序开始。我们拥有带有服务，存储库的产品资源，并且可以执行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); } }

您可能会看到我要去的地方，但这仍然可读并且可以正常工作。之后，我们又获得了三个要求。1 /我们需要致电运输服务将该产品运送到一个地址2 /如果没有足够的库存来履行订单，则抛出一个错误3 /如果产品的可用数量低于最低数量以进行重新库存。结果如下：

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); } }

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

现在到一个更好的版本

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

public class OrderService { public String placeOrder(Order order) { return orderRepository.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); } }

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

结论

如果我们从本文的第一部分开始不讨论这种情况，则应该尝试花一些时间并正确地理解我们的模型。即使出现了新的要求并且我们受到时间的压力，或者重构将花费更多的时间，我们也不应该懒惰。服务和实体中来自不同领域的混合逻辑乍一看似乎是可维护的，但随着项目规模的扩大，它变成了意大利面。就像我们在现实生活中的商店示例一样，小型的在线商店所有者可以处理从接单，进货，交付和财务等所有事务。但是，当商店发展壮大时，他将无能为力，这将变得一团糟。