今天 BGM 是 Kendrick 上張專輯中的 LOVE

今天要來探討業務邏輯的重要性，並試著實作 Service 層的設計與業務邏輯策略。

業務邏輯的重要性

業務邏輯是整個系統的核心，在裡面定義了特定的業務規則和資料操作。涵蓋了從資料驗證、計算到存儲檢索的所有事務處理。一個穩固而的業務邏輯層不僅要確保應用程式正常可靠的運行，同時也要應變快速變化的業務需求。

保持方法的職責單一 Single Responsibility Principle

單一職責原則強調一個類別或方法應該只有一個變動的原因。在 Service 層，應該確保每個方法只執行一個特定的業務操作，當一個方法只處理一個特定的任務或業務邏輯時，它變得更易於理解、測試和維護。另外，在未來遇到需求變動時也能以更少的成本進行更改。因此，在設計 Service 層的方法時需要拆分業務邏輯，讓它更具模組化並可供重用。

例如：

@Service
public class OrderService {

    public Order createOrder(OrderRequest orderRequest) {
        // 新增訂單的實作
    }

    public Order updateOrderStatus(Long orderId, OrderStatus newStatus) {
        // 更新訂單狀態的實作
    }
}

資源的有效管理

資源管理是另一個必須謹慎處理的部分。無論是資料庫連接還是外部 API 呼叫，有效的資源管理都是至關重要的事情。在微服務架構或分散式系統中，應用程式會涉及多個服務互動，例如通過 RESTful API 或 Message Queue 來通詢，如何保證資源的有效利用和防止系統承受過度負荷就是個個重要的議題。以上這些包括合理的資源分配、限流、以及降級策略的制定。

異常處理

業務邏輯經常伴隨著多種異常處理，有效的異常處理能增強程式的穩固性並提升用戶體驗。
當系統出現異常時，應該提供清楚的錯誤訊息，方便開發者進行定位問題並 debug。同時，對於不同類型的異常，可以定義不同的處理策略，例如 retry、record、或者將錯誤訊息通知給開發者。

例如：

@Service
public class ProductService {

    @Autowired
    private ProductRepository productRepository;

    public Product findProductById(Long productId) {
        return productRepository.findById(productId)
                .orElseThrow(() -> new ProductNotFoundException("Product with id " + productId + " not found"));
    }
}

這邊使用 Optional 的 orElseThrow() 拋出找不到產品 id 的 exception

業務邏輯測試

單元測試和整合測試是要確保業務邏輯按預期運作，透過撰寫測試，我們可以在開發階段就偵測到潛在問題，並確保業務流程的正確性。另外，在業務邏輯複雜的系統中，除了單元測試外，還要注意整合測試及 end-to-end 測試，確保系統在不同層、不同模組間的互動都正常運作。自動化測試和 CI/CD 也是現代軟體開發過程中一個重要的環節。

例如：

@SpringBootTest
public class OrderServiceTest {

    @Autowired
    private OrderService orderService;

    @Test
    public void createOrder_ShouldReturnOrder() {
        // 測試創建訂單的邏輯
    }
}