了解領域並建立團隊：變革的基礎（II）

著手一個複雜的專案需要全面的背景收集，同時利用領域專家的見解從全新的角度接近領域知識。這種方法使技術團隊與業務目標保持一致，並為整個產品生命週期中的明智決策建立了基礎路線圖。

與先前的團隊和目前應用程式使用者進行的初步知識收集會議被證明沒有成效。 儘管有固有風險，我們還是短暫考慮獨立進行。

EventStorming：揭開領域的面紗

身為技術主管，考慮到專案的複雜性和團隊對所有權的需求，我從一開始就倡導領域驅動的方法。這以領域為中心，促進了共同的理解（無處不在的語言），從而簡化了溝通並促進了應用程式當前狀態的映射。

我們使用 Miro 模板啟動了 EventStorming 會議，提供了有效聚焦的結構和圖例。 透過會前準備或初步解釋提前熟悉 EventStorming 概念是非常有益的。

我們的結構化 EventStorming 流程包括：

1. 探索領域事件（大局）：與領域專家一起識別、按時間順序排列和驗證關鍵系統事件，突出顯示差距和依賴性。
2. 細化和分析：添加解釋性註釋，記錄問題，深入分析每個事件，並找出關鍵決策點。
3. 領域建模：識別聚合和邊界，定義參與者和角色，建立觸發命令，記錄策略和業務規則，以及識別內部/外部事件觸發器。
4. 文件和驗證：組織和清理收集的信息，建立清晰的關係，與利害關係人驗證模型，並建立參考文件。

EventStorming 不僅提供了領域理解，還為戰略和戰術上應用領域驅動設計 (DDD) 原則奠定了基礎。

戰略領域驅動設計

關鍵的第一步涉及策略性地建構領域。 系統的複雜性和技術/業務協調的需要導致採用 DDD 原則。 上下文映射被證明是無價的，即使在我們等待重構的整體中也是如此。 我們確定了限界上下文，在具有共享核心的單一技術上下文中運行。 這種分析雖然沒有深入探討，但指導專案走向面向領域的架構，改善了技術開發和跨團隊協作。

定義邊界（有界上下文）

辨識有界上下文澄清了系統間和外部系統的關係，簡化了複雜性，為未來的模組化奠定了基礎。 這些初始決策將指導整體結構分解為與定義的上下文一致的可管理元件。 這也有助於確定優先順序並確定需要簡化、解耦或消除的領域。 我們專注於實施用於外部系統互動的反腐敗層 (ACL)，以保持系統完整性。

確定了五個關鍵背景：

• 訂單分配
• 標籤產生
• 訂單準備
• 電子商務整合
• 大量訂單準備

這些決策促進了永續架構的發展，並使開發與業務需求保持一致。

無所不在的語言

事實證明，建立強大的通用語言至關重要。 透過領域專家和開發人員之間的協作創建的共享語言的好處遠遠超過翻譯工作或誤解。 這種活躍的資源將技術團隊與領域專家聯繫起來，改善了溝通，減少了誤解，並確保程式碼中準確的領域表示。 這促進了高效、符合業務的技術解決方案。

戰術領域驅動設計

按照策略框架，我們實施了戰術 DDD 原則來建立程式碼，反映領域現實並確保長期永續性。

實體和值物件

理解實體和值物件之間的區別至關重要。

實體

實體擁有唯一、持久的身份，即使屬性改變也是如此。 例如：

• 訂單
• 產品
• 承運人
• 商店
• 顧客

值物件

值對象缺乏個體身分；他們的價值定義了他們。 相同的屬性意味著等同。 它們是不可變的，非常適合封裝跨領域出現的概念。例如：

• 產品參考
• 產品Ean13
• 訂單參考
• 價格
• 體重
• 送貨號碼

這種方法創建了更易於理解和模組化的程式碼，並具有明確定義的職責。

範例值物件：

<?php
readonly class ProductEan13
{
    public string $value;

    public function __construct(string $value)
    {
        $pattern = '/^\d{13}$/';
        if (!preg_match($pattern, $value)) {
            throw new \Exception('Invalid product Ean13');
        }
        $this->value = $value;
    }
}

服務

服務依目的和實施模式進行分類。

網域服務

網域服務封裝了不適合實體或值的業務邏輯，嚴格在網域規則內運行，無需基礎設施依賴。

<?php
readonly class ProductEan13
{
    public string $value;

    public function __construct(string $value)
    {
        $pattern = '/^\d{13}$/';
        if (!preg_match($pattern, $value)) {
            throw new \Exception('Invalid product Ean13');
        }
        $this->value = $value;
    }
}

申請服務

應用服務協調域操作與外部交互，集中複雜的操作並將域和基礎設施分開。 其中包括用例、命令處理程序和事件處理程序。

基礎設施服務

基礎設施服務處理外部元件互動（資料庫、檔案系統等），充當適配器來維護領域不可知論。

<?php
class CheapestCarrierGetter
{
    public function get(
        DeliveryOptionCarrierCollection $deliveryOptionCarriers,
        Weight $orderWeight,
        Country $country,
        PostalCode $postalCode,
        bool $isCashOnDelivery = false,
    ): Carrier {
        // Logic to get the cheapest carrier
    }
}

服務分類

服務依功能和相關設計模式分類：Transformers、Builders、Factories、Presenters、Notifiers、Validators 和 Clients。

這個最初的領域建模雖然不完整且迭代，但促進了團隊的參與和承諾。 預計將進一步完善和重組。

建議的 DDD 資源：

• 「領域驅動設計：解決軟體核心的複雜性」作者：Eric Evans
• Vaughn Vernon 的「實現領域驅動設計」
• “PHP 領域驅動設計”，作者：Carlos Buenosvinos、Christian Soronellas 和 Keyvan Akbary

組成團隊：塔克曼的階段

採用 DDD 與團隊組成並行，遵循塔克曼的階段（形成、風暴、規範、執行）。

成型

初始團隊成員審查了項目，記錄了操作，並建立了技術和組織基礎（流程、標準、工具）。

風雨飄搖

微小的分歧導致了工作方式、溝通方法和決策過程的定義。

規範

建立了團隊協議、編碼標準、開發流程、WIP 限制、部署規則、技術債管理和 ADR。

表演

建立的框架實現了高效的產品開發，優先考慮有價值的舉措，並培育持續改進的文化。

文檔：Diátaxis 模型

使用 GitLab Pages 和 Jekyll 以及 Just the Docs 主題來管理文檔，遵循 Diátaxis 模型：教程、指南、解釋和參考。 使用事件目錄和 AsyncAPI 自動化文件已規劃但尚未完全實施。

以上是了解領域並建立團隊：變革的基礎（II）的詳細內容。更多資訊請關注PHP中文網其他相關文章！