領域設計之倉儲和工廠模式！

倉儲就類似於倉庫管理員，它是聚合的管理。

倉儲介於領域模型和數據模型之間：

  • 主要用於聚合的持久化和檢索。

它隔離了領域模型和數據模型，以便我們關注於領域模型而不需要考慮如何進行持久化。

爲什麼要用倉儲

解耦領域層和基礎層

DDD 嚴格的分層架構告訴我們：

每一層只能與其下方的一層發生耦合。

因此用戶接口層只與應用層發生交互，應用層往下只與領域層發生交互，領域層往下只與基礎層發生交互。

在傳統的代碼分層結構Controller—Service—Dao結構中：

經常能看到在Service業務實現層的代碼中嵌入SQL，或者在其中頻繁出現修改數據對象並調用DAO的情況。

  • 這樣的話，基礎層的數據處理邏輯就滲透到了業務邏輯代碼中。

在DDD的分層結構中：

如果出現上述情況，則基礎層的數據處理邏輯就滲透到了領域層。

  • 領域層中的領域模型就難以聚焦在業務邏輯上，對外層的基礎層產生了依賴。

而一旦涉及到數據邏輯的修改，就要到領域層中去修改代碼。

本文要講的倉儲模式就是用來解耦領域層和基礎層的，降低他們之間的耦合和相互影響。

倉儲模式

倉儲模式包含倉儲接口和倉儲實現：

倉儲接口

  • 面向領域層提供基礎層數據處理相關的接口。

倉儲實現

  • 完成倉儲接口對應的數據持久化相關的邏輯處理。

一個聚合配備一個倉儲，由倉儲完成聚合數據的持久化。

當需要更換數據庫類型，或者更改數據處理邏輯時：

我們就可以保持業務邏輯接口不動，只修改倉儲實現，保證了領域層業務邏輯和基礎層邏輯隔離。

倉儲的架構

倉儲要依賴數據庫、內存等具體的實現工具去做真正的持久化。

如下圖所示（圖中連線代表依賴關係）：

我們可以把倉儲的行爲抽象爲基本的接口，然後利用控制反轉。

實現了倒置依賴的依賴圖如下：

實現舉例

如下示例爲一個訂單聚合中對訂單實體的倉儲模式實現。

訂單DO定義：

/**
 * 訂單聚合
 */
public class OrderDO {

    //訂單ID
    private long id;

    //訂單時間
    private long orderTime;
    
}

訂單PO定義：

/**
 * 訂單聚合的持久化PO
 */
public class OrderPO {

    //訂單ID
    private long id;

    //訂單時間
    private long orderTime;
}

倉儲接口定義：

/**
 * 訂單聚合倉儲接口
 */
public interface OrderRepository {

    /**
     * 添加訂單
     */
    void addOrder(OrderPO order);

    /**
     * 更新訂單
     */
    void updateOrder(OrderPO order);

    /**
     * 根據ID查找訂單PO對象
     */
    OrderPO findById(long id);
}

倉儲接口實現：

/**
 * 訂單倉儲實現
 */
public class OrderRepositoryImpl implements OrderRepository {

    @Resource
    private OrderDao orderDao;

    @Override
    public void addOrder(OrderPO order) {
        orderDao.addOrder(order);
    }

    @Override
    public void updateOrder(OrderPO order) {
        orderDao.updateOrder(order);
    }

    @Override
    public OrderPO findById(long id) {
        return orderDao.findById(id);
    }
}

訂單領域服務實現：

後面基礎層發生了變化，則領域層無需動任何代碼。

  • 只要倉儲接口不變，領域層的邏輯就可以一直保持不變，維護了領域層的穩定性。
/**
 * 定領域服務聚合類
 */
public class OrderDomainService {

    @Resource
    private OrderRepository orderRepository;

    public void addOrder(OrderPO order) {
        orderRepository.addOrder(order);
    }
}

Respository(倉儲) 與 DAO(數據訪問層) 的區別

之前一篇文章介紹過聚合：領域設計之理解聚合與聚合根！

在理解了聚合之後，我們可以知道：

DAO 是技術手段，Respository是抽象方式。

DAO只是針對對象的操作，而Respository是針對 聚合 的操作。

DAO的操作方式如下：

訂單和和訂單明細都有一個對應的DAO。

訂單和訂單明細的關係並沒有在對象之間得到體現。

@Service
@Transactional
public class OrderService {
    public void createOrder(Order order, List<OrderDetail> orderDetailList) throws Exception {
        Long orderId = orderDao.save(order);
        for(OrderDetail detail : orderDetailList) {
            detail.setOrderId(orderId);
            orderDetailDao.save(detail);
        }
    }
}

Respository的操作方式如下：

// 訂單和訂單明細構成聚合
public class Order {
 List<OrderDetail> orderDetail;
 ...
}
@Service
@Transactional
public class OrderService {
    public void createOrder(Order order) throws Exception {
        orderRespository.save(order);
    }
}

StackOverFlow中有一個回答，講的很好：

https://stackoverflow.com/a/11384997

工廠模式

DO對象創建時，需要確保聚合根和它依賴的對象同時被創建。

如果這項工作交給聚合根來實現，則聚合根的構造函數將變得異常龐大。

所以把通用的初始化DO的邏輯，放到工廠中去實現。

通過工廠模式封裝聚合內複雜對象的創建過程，完成聚合根，實體和值對象的創建。

  • DO對象創建時，通過倉儲從數據庫中獲取 PO 對象，通過工廠完成 PO 到 DO 的轉換。

工廠中還可以包含 DO 到PO對象的轉換過程，方便完成數據的持久化。

/**
 * Order聚合的工廠
 * DO和PO的轉換
 */
public class OrderFactory {

    /**
     * OrderPO到領域對象的數據初始化
     */
    protected Order createOrder(OrderPO orderPO){
        Order order = new Order();
        order.setId(orderPO.getId());
        order.setOrderTime(orderPO.getOrderTime());
        return order;
    }

    /**
     * 領域對象到持久化對象PO的轉換
     */
    protected OrderPO createOrderPO(Order order){
        OrderPO orderPO = new OrderPO();
        orderPO.setId(order.getId());
        orderPO.setOrderTime(order.getOrderTime());
        return orderPO;
    }
    
}

參考資料：

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Q3wqI0FuVBM8bekIg8hwwQ

猜你喜歡