# 訂單結帳流程（空間）

## 實體
`空間`、`使用者`、`訂單`、`結帳流程`、`付款`、`發票`、`門鎖`

**空間**
- 判斷自身可被預訂的時間
- 空間狀態是否可被預訂

**使用者**
- 依照情境判斷該使用者其身份
- 使用者可折抵的點數？
- 使用者可折抵的時數？

**身份**

**訂單**
- 記錄依照結帳流程後，產生的各項紀錄資料
- 管理訂單明細

**付款**
- 信用卡、街口...

**結帳流程**
- 時數的折抵？
- 點數的折抵？
- 優惠卷的折抵？
- 付款
\* 依據`結帳流程`的過程去變動訂單資訊的狀態

**門鎖**
- 產生門鎖資訊
- 回傳門鎖資訊

**發票 (預訂流程責任)**
- 開立發票
- 回傳發票資訊

## 現有流程
目前看待付款的方式將`身份`（業主、暢遊、內部...）、`點數`、`信用卡`、`街口`，都拉為通一層級視為付款方式，但其付款方式又可以互相並存共用，導致付款的判斷過程需判斷各項組合結果，並照成在個自款方式上處理完整的結帳流程包含後續的`訂單`、`發票`、`門鎖`、`通知`處理，重複程式碼散在各地。

職權責任並沒有分清楚，全部散落在`OrderSubmitServices`裡面

## 重構改善

<?php

class OrderSubmitService {
    public function booked(Request $request) {

        // 預處理 request 資料    
        // 1. request 資料是否齊全
        ...
            
        // 2. 空間是否可預訂
        $canOrder = Space::canBooked(...);
        
        // 3. 產生基礎訂單
        $order = Order::create(...);
        
        // 4. 結帳流程
        $response = CheckoutProcess::checkout($order, ...);
        
        if(!$response) {
            // return 結果失敗處理
        }
        
        // 5. 開立發票
        Invoice::create(...);
        
        // 6. 門鎖資訊建立
        Door::create(...);
        
        // return 成功結果畫面
    }
}

<?php
class CheckoutProcess {
    
    protected state = {
        紀錄訂單目前狀態...
        該預訂使用的付款選擇...
    }
    
    public function checkout() {
        $this->hourprocess();
        
        $this->pointprocess();
        
        $this->cashprocess();
        
        return state;
    }
    
    public function hourprocess() {
        //判斷是否需要使用時數折抵

        //處理訂單與時數之間關係        
        
        //更改 state 內容
    }
    
    public function pointprocess() {
        //判斷是否需要使用點數折抵

        //處理訂單與點數之間關係        
        
        //更改 state 內容
    }
    
    public function cashprocess() {
        // 依照 state 的狀態（訂單金額是否被折抵為0，選擇的付款方式）
        
        // 信用卡 or 街口
        
        //更改 state 內容
    }
}

2022.04.14 會後紀錄
- 針對實體進行責任歸屬討論
- 實體`身份`獨立出來，但遇到分份重複問題如何解決？

2022.04.25
- 針對分歧的部分，實作虛擬碼流程，針對程式碼來討論（結帳部分）