阿裡技術專家詳解DDD系列第四講 - 領域層設計規範

原創｜阿裡巴巴淘系技術

在一個DDD架構設計中，領域層的設計合理性會直接影響整個架構的代碼結構以及應用層、基礎設施層的設計。但是領域層設計又是有挑戰的任務，特别是在一個業務邏輯相對複雜應用中，每一個業務規則是應該放在Entity、ValueObject 還是 DomainService是值得用心思考的，既要避免未來的擴充性差，又要確定不會過度設計導緻複雜性。

今天我用一個相對輕松易懂的領域做一個案例示範，但在實際業務應用中，無論是交易、營銷還是互動，都可以用類似的邏輯來實作。

初探龍與魔法的世界架構

▐ 背景和規則

平日裡看了好多嚴肅的業務代碼，今天找一個輕松的話題，如何用代碼實作一個龍與魔法的遊戲世界的（極簡）規則？

基礎配置如下：

玩家（Player）可以是戰士（Fighter）、法師（Mage）、龍騎（Dragoon）
怪物（Monster）可以是獸人（Orc）、精靈（Elf）、龍（Dragon），怪物有血量
武器（Weapon）可以是劍（Sword）、法杖（Staff），武器有攻擊力
玩家可以裝備一個武器，武器攻擊可以是實體類型（0），火（1），冰（2）等，武器類型決定傷害類型

攻擊規則如下：

獸人對實體攻擊傷害減半
精靈對魔法攻擊傷害減半
龍對實體和魔法攻擊免疫，除非玩家是龍騎，則傷害加倍

▐ OOP實作

對于熟悉Object-Oriented Programming的同學，一個比較簡單的實作是通過類的繼承關系（此處省略部分非核心代碼）：

public abstract class Player {
      Weapon weapon
}
public class Fighter extends Player {}
public class Mage extends Player {}
public class Dragoon extends Player {}

public abstract class Monster {
    Long health;
}
public Orc extends Monster {}
public Elf extends Monster {}
public Dragoon extends Monster {}

public abstract class Weapon {
    int damage;
    int damageType; // 0 - physical, 1 - fire, 2 - ice etc.
}
public Sword extends Weapon {}
public Staff extends Weapon {}

而實作規則代碼如下：

public class Player {
    public void attack(Monster monster) {
        monster.receiveDamageBy(weapon, this);
    }
}

public class Monster {
    public void receiveDamageBy(Weapon weapon, Player player) {
        this.health -= weapon.getDamage(); // 基礎規則
    }
}

public class Orc extends Monster {
    @Override
    public void receiveDamageBy(Weapon weapon, Player player) {
        if (weapon.getDamageType() == 0) {
            this.setHealth(this.getHealth() - weapon.getDamage() / 2); // Orc的實體防禦規則
        } else {
            super.receiveDamageBy(weapon, player);
        }
    }
}

public class Dragon extends Monster {
    @Override
    public void receiveDamageBy(Weapon weapon, Player player) {
        if (player instanceof Dragoon) {
            this.setHealth(this.getHealth() - weapon.getDamage() * 2); // 龍騎傷害規則
        }
        // else no damage, 龍免疫力規則
    }
}

然後跑幾個單測：

public class BattleTest {

    @Test
    @DisplayName("Dragon is immune to attacks")
    public void testDragonImmunity() {
        // Given
        Fighter fighter = new Fighter("Hero");
        Sword sword = new Sword("Excalibur", 10);
        fighter.setWeapon(sword);
        Dragon dragon = new Dragon("Dragon", 100L);

        // When
        fighter.attack(dragon);

        // Then
        assertThat(dragon.getHealth()).isEqualTo(100);
    }

    @Test
    @DisplayName("Dragoon attack dragon doubles damage")
    public void testDragoonSpecial() {
        // Given
        Dragoon dragoon = new Dragoon("Dragoon");
        Sword sword = new Sword("Excalibur", 10);
        dragoon.setWeapon(sword);
        Dragon dragon = new Dragon("Dragon", 100L);

        // When
        dragoon.attack(dragon);

        // Then
        assertThat(dragon.getHealth()).isEqualTo(100 - 10 * 2);
    }

    @Test
    @DisplayName("Orc should receive half damage from physical weapons")
    public void testFighterOrc() {
        // Given
        Fighter fighter = new Fighter("Hero");
        Sword sword = new Sword("Excalibur", 10);
        fighter.setWeapon(sword);
        Orc orc = new Orc("Orc", 100L);

        // When
        fighter.attack(orc);

        // Then
        assertThat(orc.getHealth()).isEqualTo(100 - 10 / 2);
    }

    @Test
    @DisplayName("Orc receive full damage from magic attacks")
    public void testMageOrc() {
        // Given
        Mage mage = new Mage("Mage");
        Staff staff = new Staff("Fire Staff", 10);
        mage.setWeapon(staff);
        Orc orc = new Orc("Orc", 100L);

        // When
        mage.attack(orc);

        // Then
        assertThat(orc.getHealth()).isEqualTo(100 - 10);
    }
}

以上代碼和單測都比較簡單，不做多餘的解釋了。

▐ 分析OOP代碼的設計缺陷

程式設計語言的強類型無法承載業務規則

以上的OOP代碼可以跑得通，直到我們加一個限制條件：

戰士隻能裝備劍
法師隻能裝備法杖

這個規則在Java語言裡無法通過強類型來實作，雖然Java有Variable Hiding（或者C#的new class variable），但實際上隻是在子類上加了一個新變量，是以會導緻以下的問題：

@Data
public class Fighter extends Player {
    private Sword weapon;
}

@Test
public void testEquip() {
    Fighter fighter = new Fighter("Hero");

    Sword sword = new Sword("Sword", 10);
    fighter.setWeapon(sword);

    Staff staff = new Staff("Staff", 10);
    fighter.setWeapon(staff);

    assertThat(fighter.getWeapon()).isInstanceOf(Staff.class); // 錯誤了
}

在最後，雖然代碼感覺是setWeapon(Staff)，但實際上隻修改了父類的變量，并沒有修改子類的變量，是以實際不生效，也不抛異常，但結果是錯的。

當然，可以在父類限制setter為protected，但這樣就限制了父類的API，極大的降低了靈活性，同時也違背了Liskov substitution principle，即一個父類必須要cast成子類才能使用：

@Data
public abstract class Player {
    @Setter(AccessLevel.PROTECTED)
    private Weapon weapon;
}

@Test
public void testCastEquip() {
    Fighter fighter = new Fighter("Hero");

    Sword sword = new Sword("Sword", 10);
    fighter.setWeapon(sword);

    Player player = fighter;
    Staff staff = new Staff("Staff", 10);
    player.setWeapon(staff); // 編譯不過，但從API層面上應該開放可用
}

最後，如果規則增加一條：

戰士和法師都能裝備匕首（dagger）

BOOM，之前寫的強類型代碼都廢了，需要重構。

對象繼承導緻代碼強依賴父類邏輯，違反開閉原則Open-Closed Principle（OCP）

開閉原則（OCP）規定“對象應該對于擴充開放，對于修改封閉“，繼承雖然可以通過子類擴充新的行為，但因為子類可能直接依賴父類的實作，導緻一個變更可能會影響所有對象。在這個例子裡，如果增加任意一種類型的玩家、怪物或武器，或增加一種規則，都有可能需要修改從父類到子類的所有方法。

比如，如果要增加一個武器類型：狙擊槍，能夠無視所有防禦一擊必殺，需要修改的代碼包括：

Weapon
Player和所有的子類（是否能裝備某個武器的判斷）
Monster和所有的子類（傷害計算邏輯）

public class Monster {
    public void receiveDamageBy(Weapon weapon, Player player) {
        this.health -= weapon.getDamage(); // 老的基礎規則
        if (Weapon instanceof Gun) { // 新的邏輯
            this.setHealth(0);
        }
    }
}

public class Dragon extends Monster {
    public void receiveDamageBy(Weapon weapon, Player player) {
        if (Weapon instanceof Gun) { // 新的邏輯
                      super.receiveDamageBy(weapon, player);
        }
        // 老的邏輯省略
    }
}

在一個複雜的軟體中為什麼會建議“盡量”不要違背OCP？最核心的原因就是一個現有邏輯的變更可能會影響一些原有的代碼，導緻一些無法預見的影響。這個風險隻能通過完整的單元測試覆寫來保障，但在實際開發中很難保障單測的覆寫率。OCP的原則能盡可能的規避這種風險，當新的行為隻能通過新的字段/方法來實作時，老代碼的行為自然不會變。

繼承雖然能Open for extension，但很難做到Closed for modification。是以今天解決OCP的主要方法是通過Composition-over-inheritance，即通過組合來做到擴充性，而不是通過繼承。

Player.attack(monster) 還是 Monster.receiveDamage(Weapon, Player)？

在這個例子裡，其實業務規則的邏輯到底應該寫在哪裡是有異議的：當我們去看一個對象和另一個對象之間的互動時，到底是Player去攻擊Monster，還是Monster被Player攻擊？目前的代碼主要将邏輯寫在Monster的類中，主要考慮是Monster會受傷降低Health，但如果是Player拿着一把雙刃劍會同時傷害自己呢？是不是發現寫在Monster類裡也有問題？代碼寫在哪裡的原則是什麼？

多對象行為類似，導緻代碼重複

當我們有不同的對象，但又有相同或類似的行為時，OOP會不可避免的導緻代碼的重複。在這個例子裡，如果我們去增加一個“可移動”的行為，需要在Player和Monster類中都增加類似的邏輯：

public abstract class Player {
    int x;
    int y;
    void move(int targetX, int targetY) {
        // logic
    }
}

public abstract class Monster {
    int x;
    int y;
    void move(int targetX, int targetY) {
        // logic
    }
}

一個可能的解法是有個通用的父類：

public abstract class Movable {
    int x;
    int y;
    void move(int targetX, int targetY) {
        // logic
    }
}

public abstract class Player extends Movable;
public abstract class Monster extends Movable;

但如果再增加一個跳躍能力Jumpable呢？一個跑步能力Runnable呢？如果Player可以Move和Jump，Monster可以Move和Run，怎麼處理繼承關系？要知道Java（以及絕大部分語言）是不支援多父類繼承的，是以隻能通過重複代碼來實作。

問題總結

在這個案例裡雖然從直覺來看OOP的邏輯很簡單，但如果你的業務比較複雜，未來會有大量的業務規則變更時，簡單的OOP代碼會在後期變成複雜的一團漿糊，邏輯分散在各地，缺少全局視角，各種規則的疊加會觸發bug。有沒有感覺似曾相識？對的，電商體系裡的優惠、交易等鍊路經常會碰到類似的坑。而這類問題的核心本質在于：

業務規則的歸屬到底是對象的“行為”還是獨立的”規則對象“？
業務規則之間的關系如何處理？
通用“行為”應該如何複用和維護？

在講DDD的解法前，我們先去看看一套遊戲裡最近比較火的架構設計，Entity-Component-System（ECS）是如何實作的。

Entity-Component-System（ECS）架構簡介

▐ ECS介紹

ECS架構模式是其實是一個很老的遊戲架構設計，最早應該能追溯到《地牢圍攻》的元件化設計，但最近因為Unity的加入而開始變得流行（比如《守望先鋒》就是用的ECS）。要很快的了解ECS架構的價值，我們需要了解一個遊戲代碼的核心問題：

性能：遊戲必須要實作一個高的渲染率（60FPS），也就是說整個遊戲世界需要在1/60s（大概16ms）内完整更新一次（包括實體引擎、遊戲狀态、渲染、AI等）。而在一個遊戲中，通常有大量的（萬級、十萬級）遊戲對象需要更新狀态，除了渲染可以依賴GPU之外，其他的邏輯都需要由CPU完成，甚至絕大部分隻能由單線程完成，導緻絕大部分時間複雜場景下CPU（主要是記憶體到CPU的帶寬）會成為瓶頸。在CPU單核速度幾乎不再增加的時代，如何能讓CPU處理的效率提升，是提升遊戲性能的核心。
代碼組織：如同第一章講的案例一樣，當我們用傳統OOP的模式進行遊戲開發時，很容易就會陷入代碼組織上的問題，最終導緻代碼難以閱讀，維護和優化。
可擴充性：這個跟上一條類似，但更多的是遊戲的特性導緻：需要快速更新，加入新的元素。一個遊戲的架構需要能通過低代碼、甚至0代碼的方式增加遊戲元素，進而通過快速更新而留住使用者。如果每次變更都需要開發新的代碼，測試，然後讓使用者重新下載下傳用戶端，可想而知這種遊戲很難在現在的競争環境下活下來。

而ECS架構能很好的解決上面的幾個問題，ECS架構主要分為：

Entity：用來代表任何一個遊戲對象，但是在ECS裡一個Entity最重要的僅僅是他的EntityID，一個Entity裡包含多個Component
Component：是真正的資料，ECS架構把一個個的實體對象拆分為更加細化的元件，比如位置、素材、狀态等，也就是說一個Entity實際上隻是一個Bag of Components。
System（或者ComponentSystem，元件系統）：是真正的行為，一個遊戲裡可以有很多個不同的元件系統，每個元件系統都隻負責一件事，可以依次處理大量的相同元件，而不需要去了解具體的Entity。是以一個ComponentSystem理論上可以有更加高效的元件處理效率，甚至可以實作并行處理，進而提升CPU使用率。

ECS的一些核心性能優化包括将同類型元件放在同一個Array中，然後Entity僅保留到各自元件的pointer，這樣能更好的利用CPU的緩存，減少資料的加載成本，以及SIMD的優化等。

一個ECS案例的僞代碼如下：

由于本文不是講解ECS架構的，感興趣的同學可以搜尋Entity-Component-System或者看看Unity的ECS文檔等。

▐ ECS架構分析

重新回來分析ECS，其實它的本源還是幾個很老的概念：

元件化

在軟體系統裡，我們通常将複雜的大系統拆分為獨立的元件，來降低複雜度。比如網頁裡通過前端元件化降低重複開發成本，微服務架構通過服務和資料庫的拆分降低服務複雜度和系統影響面等。但是ECS架構把這個走到了極緻，即每個對象内部都實作了元件化。通過将一個遊戲對象的資料和行為拆分為多個元件群組件系統，能實作元件的高度複用性，降低重複開發成本。

行為抽離

這個在遊戲系統裡有個比較明顯的優勢。如果按照OOP的方式，一個遊戲對象裡可能會包括移動代碼、戰鬥代碼、渲染代碼、AI代碼等，如果都放在一個類裡會很長，且很難去維護。通過将通用邏輯抽離出來為單獨的System類，可以明顯提升代碼的可讀性。另一個好處則是抽離了一些和對象代碼無關的依賴，比如上文的delta，這個delta如果是放在Entity的update方法，則需要作為入參注入，而放在System裡則可以統一管理。在第一章的有個問題，到底是應該Player.attack(monster) 還是 Monster.receiveDamage(Weapon, Player)。在ECS裡這個問題就變的很簡單，放在CombatSystem裡就可以了。

資料驅動

即一個對象的行為不是寫死的而是通過其參數決定，通過參數的動态修改，就可以快速改變一個對象的具體行為。在ECS的遊戲架構裡，通過給Entity注冊相應的Component，以及改變Component的具體參數的組合，就可以改變一個對象的行為和玩法，比如建立一個水壺+爆炸屬性就變成了“爆炸水壺”、給一個自行車加上風魔法就變成了飛車等。在有些Rougelike遊戲中，可能有超過1萬件不同類型、不同功能的物品，如果這些不同功能的物品都去單獨寫代碼，可能永遠都寫不完，但是通過資料驅動+元件化架構，所有物品的配置最終就是一張表，修改也極其簡單。這個也是組合勝于繼承原則的一次展現。

▐ ECS的缺陷

雖然ECS在遊戲界已經開始嶄露頭角，我發現ECS架構目前還沒有在哪個大型商業應用中被使用過。原因可能很多，包括ECS比較新大家還不了解、缺少商業成熟可用的架構、程式員們還不夠能适應從寫邏輯腳本到寫元件的思維轉變等，但我認為其最大的一個問題是ECS為了提升性能，強調了資料/狀态（State）和行為（Behaivor）分離，并且為了降低GC成本，直接操作資料，走到了一個極端。而在商業應用中，資料的正确性、一緻性和健壯性應該是最高的優先級，而性能隻是錦上添花的東西，是以ECS很難在商業場景裡帶來特别大的好處。但這不代表我們不能借鑒一些ECS的突破性思維，包括元件化、跨對象行為的抽離、以及資料驅動模式，而這些在DDD裡也能很好的用起來。

基于DDD架構的一種解法

▐ 領域對象

回到我們原來的問題域上面，我們從領域層拆分一下各種對象：

實體類

在DDD裡，實體類包含ID和内部狀态，在這個案例裡實體類包含Player、Monster和Weapon。Weapon被設計成實體類是因為兩把同名的Weapon應該可以同時存在，是以必須要有ID來區分，同時未來也可以預期Weapon會包含一些狀态，比如更新、臨時的buff、耐久等。

public class Player implements Movable {
    private PlayerId id;
    private String name;
    private PlayerClass playerClass; // enum
    private WeaponId weaponId; // （Note 1）
    private Transform position = Transform.ORIGIN;
    private Vector velocity = Vector.ZERO;
}

public class Monster implements Movable {
    private MonsterId id;
    private MonsterClass monsterClass; // enum
    private Health health;
    private Transform position = Transform.ORIGIN;
    private Vector velocity = Vector.ZERO;
}

public class Weapon {
    private WeaponId id;
    private String name;
    private WeaponType weaponType; // enum
    private int damage;
    private int damageType; // 0 - physical, 1 - fire, 2 - ice
}

在這個簡單的案例裡，我們可以利用enum的PlayerClass、MonsterClass來代替繼承關系，後續也可以利用Type Object設計模式來做到資料驅動。

Note 1: 因為 Weapon 是實體類，但是Weapon能獨立存在，Player不是聚合根，是以Player隻能儲存WeaponId，而不能直接指向Weapon。

值對象的元件化

在前面的ECS架構裡，有個MovementSystem的概念是可以複用的，雖然不應該直接去操作Component或者繼承通用的父類，但是可以通過接口的方式對領域對象做元件化處理：

pubpublic interface Movable {
    // 相當于元件
    Transform getPosition();
    Vector getVelocity();

    // 行為
    void moveTo(long x, long y);
    void startMove(long velX, long velY);
    void stopMove();
    boolean isMoving();
}

// 具體實作
public class Player implements Movable {
    public void moveTo(long x, long y) {
        this.position = new Transform(x, y);
    }

    public void startMove(long velocityX, long velocityY) {
        this.velocity = new Vector(velocityX, velocityY);
    }

    public void stopMove() {
        this.velocity = Vector.ZERO;
    }

    @Override
    public boolean isMoving() {
        return this.velocity.getX() != 0 || this.velocity.getY() != 0;
    }
}

@Value
public class Transform {
    public static final Transform ORIGIN = new Transform(0, 0);
    long x;
    long y;
}

@Value
public class Vector {
    public static final Vector ZERO = new Vector(0, 0);
    long x;
    long y;
}

注意兩點：

Moveable的接口沒有Setter。一個Entity的規則是不能直接變更其屬性，必須通過Entity的方法去對内部狀态做變更。這樣能保證資料的一緻性。
抽象Movable的好處是如同ECS一樣，一些特别通用的行為（如在大地圖裡移動）可以通過統一的System代碼去處理，避免了重複勞動。

▐ 裝備行為

因為我們已經不會用Player的子類來決定什麼樣的Weapon可以裝備，是以這段邏輯應該被拆分到一個單獨的類裡。這種類在DDD裡被叫做領域服務（Domain Service）。

public interface EquipmentService {
    boolean canEquip(Player player, Weapon weapon);
}

在DDD裡，一個Entity不應該直接參考另一個Entity或服務，也就是說以下的代碼是錯誤的：

public class Player {
    @Autowired
    EquipmentService equipmentService; // BAD: 不可以直接依賴

    public void equip(Weapon weapon) {
       // ...
    }
}

這裡的問題是Entity隻能保留自己的狀态（或非聚合根的對象）。任何其他的對象，無論是否通過依賴注入的方式弄進來，都會破壞Entity的Invariance，并且還難以單測。

正确的引用方式是通過方法參數引入（Double Dispatch）：

public class Player {

    public void equip(Weapon weapon, EquipmentService equipmentService) {
        if (equipmentService.canEquip(this, weapon)) {
            this.weaponId = weapon.getId();
        } else {
            throw new IllegalArgumentException("Cannot Equip: " + weapon);
        }
    }
}

在這裡，無論是Weapon還是EquipmentService都是通過方法參數傳入，確定不會污染Player的自有狀态。

Double Dispatch是一個使用Domain Service經常會用到的方法，類似于調用反轉。

然後在EquipmentService裡實作相關的邏輯判斷，這裡我們用了另一個常用的Strategy（或者叫Policy）設計模式：

public class EquipmentServiceImpl implements EquipmentService {
    private EquipmentManager equipmentManager; 

    @Override
    public boolean canEquip(Player player, Weapon weapon) {
        return equipmentManager.canEquip(player, weapon);
    }
}

// 政策優先級管理
public class EquipmentManager {
    private static final List<EquipmentPolicy> POLICIES = new ArrayList<>();
    static {
        POLICIES.add(new FighterEquipmentPolicy());
        POLICIES.add(new MageEquipmentPolicy());
        POLICIES.add(new DragoonEquipmentPolicy());
        POLICIES.add(new DefaultEquipmentPolicy());
    }

    public boolean canEquip(Player player, Weapon weapon) {
        for (EquipmentPolicy policy : POLICIES) {
            if (!policy.canApply(player, weapon)) {
                continue;
            }
            return policy.canEquip(player, weapon);
        }
        return false;
    }
}

// 政策案例
public class FighterEquipmentPolicy implements EquipmentPolicy {

    @Override
    public boolean canApply(Player player, Weapon weapon) {
        return player.getPlayerClass() == PlayerClass.Fighter;
    }

    /**
     * Fighter能裝備Sword和Dagger
     */
    @Override
    public boolean canEquip(Player player, Weapon weapon) {
        return weapon.getWeaponType() == WeaponType.Sword
                || weapon.getWeaponType() == WeaponType.Dagger;
    }
}

// 其他政策省略，見源碼

這樣設計的最大好處是未來的規則增加隻需要添加新的Policy類，而不需要去改變原有的類。

▐ 攻擊行為

在上文中曾經有提起過，到底應該是Player.attack(Monster)還是Monster.receiveDamage(Weapon, Player)？在DDD裡，因為這個行為可能會影響到Player、Monster和Weapon，是以屬于跨實體的業務邏輯。在這種情況下需要通過一個第三方的領域服務（Domain Service）來完成。

public interface CombatService {
    void performAttack(Player player, Monster monster);
}

public class CombatServiceImpl implements CombatService {
    private WeaponRepository weaponRepository;
    private DamageManager damageManager;

    @Override
    public void performAttack(Player player, Monster monster) {
        Weapon weapon = weaponRepository.find(player.getWeaponId());
        int damage = damageManager.calculateDamage(player, weapon, monster);
        if (damage > 0) {
            monster.takeDamage(damage); // （Note 1）在領域服務裡變更Monster
        }
        // 省略掉Player和Weapon可能受到的影響
    }
}

同樣的在這個案例裡，可以通過Strategy設計模式來解決damage的計算問題：

// 政策優先級管理
public class DamageManager {
    private static final List<DamagePolicy> POLICIES = new ArrayList<>();
    static {
        POLICIES.add(new DragoonPolicy());
        POLICIES.add(new DragonImmunityPolicy());
        POLICIES.add(new OrcResistancePolicy());
        POLICIES.add(new ElfResistancePolicy());
        POLICIES.add(new PhysicalDamagePolicy());
        POLICIES.add(new DefaultDamagePolicy());
    }

    public int calculateDamage(Player player, Weapon weapon, Monster monster) {
        for (DamagePolicy policy : POLICIES) {
            if (!policy.canApply(player, weapon, monster)) {
                continue;
            }
            return policy.calculateDamage(player, weapon, monster);
        }
        return 0;
    }
}

// 政策案例
public class DragoonPolicy implements DamagePolicy {
    public int calculateDamage(Player player, Weapon weapon, Monster monster) {
        return weapon.getDamage() * 2;
    }
    @Override
    public boolean canApply(Player player, Weapon weapon, Monster monster) {
        return player.getPlayerClass() == PlayerClass.Dragoon &&
                monster.getMonsterClass() == MonsterClass.Dragon;
    }
}

特别需要注意的是這裡的CombatService領域服務和3.2的EquipmentService領域服務，雖然都是領域服務，但實質上有很大的差異。上文的EquipmentService更多的是提供隻讀政策，且隻會影響單個對象，是以可以在Player.equip方法上通過參數注入。但是CombatService有可能會影響多個對象，是以不能直接通過參數注入的方式調用。

▐ 單元測試

@@Test
@DisplayName("Dragoon attack dragon doubles damage")
public void testDragoonSpecial() {
    // Given
    Player dragoon = playerFactory.createPlayer(PlayerClass.Dragoon, "Dart");
    Weapon sword = weaponFactory.createWeaponFromPrototype(swordProto, "Soul Eater", 60);
    ((WeaponRepositoryMock)weaponRepository).cache(sword);
    dragoon.equip(sword, equipmentService);
    Monster dragon = monsterFactory.createMonster(MonsterClass.Dragon, 100);

    // When
    combatService.performAttack(dragoon, dragon);

    // Then
    assertThat(dragon.getHealth()).isEqualTo(Health.ZERO);
    assertThat(dragon.isAlive()).isFalse();
}

@Test
@DisplayName("Orc should receive half damage from physical weapons")
public void testFighterOrc() {
    // Given
    Player fighter = playerFactory.createPlayer(PlayerClass.Fighter, "MyFighter");
    Weapon sword = weaponFactory.createWeaponFromPrototype(swordProto, "My Sword");
    ((WeaponRepositoryMock)weaponRepository).cache(sword);
    fighter.equip(sword, equipmentService);
    Monster orc = monsterFactory.createMonster(MonsterClass.Orc, 100);

    // When
    combatService.performAttack(fighter, orc);

    // Then
    assertThat(orc.getHealth()).isEqualTo(Health.of(100 - 10 / 2));
}

具體的代碼比較簡單，解釋省略

▐ 移動系統

最後還有一種Domain Service，通過元件化，我們其實可以實作ECS一樣的System，來降低一些重複性的代碼：

public class MovementSystem {

    private static final long X_FENCE_MIN = -100;
    private static final long X_FENCE_MAX = 100;
    private static final long Y_FENCE_MIN = -100;
    private static final long Y_FENCE_MAX = 100;

    private List<Movable> entities = new ArrayList<>();

    public void register(Movable movable) {
        entities.add(movable);
    }

    public void update() {
        for (Movable entity : entities) {
            if (!entity.isMoving()) {
                continue;
            }

            Transform old = entity.getPosition();
            Vector vel = entity.getVelocity();
            long newX = Math.max(Math.min(old.getX() + vel.getX(), X_FENCE_MAX), X_FENCE_MIN);
            long newY = Math.max(Math.min(old.getY() + vel.getY(), Y_FENCE_MAX), Y_FENCE_MIN);
            entity.moveTo(newX, newY);
        }
    }
}

單測：

@Test
@DisplayName("Moving player and monster at the same time")
public void testMovement() {
    // Given
    Player fighter = playerFactory.createPlayer(PlayerClass.Fighter, "MyFighter");
    fighter.moveTo(2, 5);
    fighter.startMove(1, 0);

    Monster orc = monsterFactory.createMonster(MonsterClass.Orc, 100);
    orc.moveTo(10, 5);
    orc.startMove(-1, 0);

    movementSystem.register(fighter);
    movementSystem.register(orc);

    // When
    movementSystem.update();

    // Then
    assertThat(fighter.getPosition().getX()).isEqualTo(2 + 1);
    assertThat(orc.getPosition().getX()).isEqualTo(10 - 1);
}

在這裡MovementSystem就是一個相對獨立的Domain Service，通過對Movable的元件化，實作了類似代碼的集中化、以及一些通用依賴/配置的中心化（如X、Y邊界等）。

DDD領域層的一些設計規範

上面我主要針對同一個例子對比了OOP、ECS和DDD的3種實作，比較如下：

基于繼承關系的OOP代碼：OOP的代碼最好寫，也最容易了解，所有的規則代碼都寫在對象裡，但是當領域規則變得越來越複雜時，其結構會限制它的發展。新的規則有可能會導緻代碼的整體重構。
基于元件化的ECS代碼：ECS代碼有最高的靈活性、可複用性、及性能，但極具弱化了實體類的内聚，所有的業務邏輯都寫在了服務裡，會導緻業務的一緻性無法保障，對商業系統會有較大的影響。
基于領域對象 + 領域服務的DDD架構：DDD的規則其實最複雜，同時要考慮到實體類的内聚和保證不變性（Invariants），也要考慮跨對象規則代碼的歸屬，甚至要考慮到具體領域服務的調用方式，了解成本比較高。

是以下面，我會盡量通過一些設計規範，來降低DDD領域層的設計成本。領域層裡的Value Object（Domain Primitive）設計規範請參考我之前的文章。

▐ 實體類（Entity）

大多數DDD架構的核心都是實體類，實體類包含了一個領域裡的狀态、以及對狀态的直接操作。Entity最重要的設計原則是保證明體的不變性（Invariants），也就是說要確定無論外部怎麼操作，一個實體内部的屬性都不能出現互相沖突，狀态不一緻的情況。是以幾個設計原則如下：

建立即一緻

在貧血模型裡，通常見到的代碼是一個模型通過手動new出來之後，由調用方一個參數一個參數的指派，這就很容易産生遺漏，導緻實體狀态不一緻。是以DDD裡實體建立的方法有兩種：

constructor參數要包含所有必要屬性，或者在constructor裡有合理的預設值。

比如，賬号的建立：

public class Account {
    private String accountNumber;
    private Long amount;
}

@Test
public void test() {
    Account account = new Account();
    account.setAmount(100L);
    TransferService.transfer(account); // 報錯了，因為Account缺少必要的AccountNumber
}

如果缺少一個強校驗的constructor，就無法保障建立的實體的一緻性。是以需要增加一個強校驗的constructor：

public class Account {
    public Account(String accountNumber, Long amount) {
        assert StringUtils.isNotBlank(accountNumber);
        assert amount >= 0;
        this.accountNumber = accountNumber;
        this.amount = amount;
    }
}

@Test
public void test() {
    Account account = new Account("123", 100L); // 確定對象的有效性
}

使用Factory模式來降低調用方複雜度

另一種方法是通過Factory模式來建立對象，降低一些重複性的入參。比如：

public class WeaponFactory {
    public Weapon createWeaponFromPrototype(WeaponPrototype proto, String newName) {
        Weapon weapon = new Weapon(null, newName, proto.getWeaponType(), proto.getDamage(), proto.getDamageType());
        return weapon;
    }
}

通過傳入一個已經存在的Prototype，可以快速的建立新的實體。還有一些其他的如Builder等設計模式就不一一指出了。

盡量避免public setter

一個最容易導緻不一緻性的原因是實體暴露了public的setter方法，特别是set單一參數會導緻狀态不一緻的情況。比如，一個訂單可能包含訂單狀态（下單、已支付、已發貨、已收貨）、支付單、物流單等子實體，如果一個調用方能随意去set訂單狀态，就有可能導緻訂單狀态和子實體比對不上，導緻業務流程走不通的情況。是以在實體裡，需要通過行為方法來修改内部狀态：

@Data @Setter(AccessLevel.PRIVATE) // 確定不生成public setter
public class Order {
    private int status; // 0 - 建立，1 - 支付，2 - 發貨，3 - 收貨
    private Payment payment; // 支付單
    private Shipping shipping; // 物流單

    public void pay(Long userId, Long amount) {
        if (status != 0) {
            throw new IllegalStateException();
        }
        this.status = 1;
        this.payment = new Payment(userId, amount);
    }

    public void ship(String trackingNumber) {
        if (status != 1) {
            throw new IllegalStateException();
        }
        this.status = 2;
        this.shipping = new Shipping(trackingNumber);
    }
}

【建議】在有些簡單場景裡，有時候确實可以比較随意的設定一個值而不會導緻不一緻性，也建議将方法名重新寫為比較“行為化”的命名，會增強其語意。比如setPosition(x, y)可以叫做moveTo(x, y)，setAddress可以叫做assignAddress等。

通過聚合根保證主子實體的一緻性

在稍微複雜一點的領域裡，通常主實體會包含子實體，這時候主實體就需要起到聚合根的作用，即：

子實體不能單獨存在，隻能通過聚合根的方法擷取到。任何外部的對象都不能直接保留子實體的引用
子實體沒有獨立的Repository，不可以單獨儲存和取出，必須要通過聚合根的Repository執行個體化
子實體可以單獨修改自身狀态，但是多個子實體之間的狀态一緻性需要聚合根來保障

常見的電商域中聚合的案例如主子訂單模型、商品/SKU模型、跨子訂單優惠、跨店優惠模型等。很多聚合根和Repository的設計規範在我前面一篇關于Repository的文章中已經詳細解釋過，可以拿來參考。

不可以強依賴其他聚合根實體或領域服務

一個實體的原則是高内聚、低耦合，即一個實體類不能直接在内部直接依賴一個外部的實體或服務。這個原則和絕大多數ORM架構都有比較嚴重的沖突，是以是一個在開發過程中需要特别注意的。這個原則的必要原因包括：對外部對象的依賴性會直接導緻實體無法被單測；以及一個實體無法保證外部實體變更後不會影響本實體的一緻性和正确性。

是以，正确的對外部依賴的方法有兩種：

隻儲存外部實體的ID：這裡我再次強烈建議使用強類型的ID對象，而不是Long型ID。強類型的ID對象不單單能自我包含驗證代碼，保證ID值的正确性，同時還能確定各種入參不會因為參數順序變化而出bug。具體可以參考我的Domain Primitive文章。
針對于“無副作用”的外部依賴，通過方法入參的方式傳入。比如上文中的equip(Weapon，EquipmentService）方法。

如果方法對外部依賴有副作用，不能通過方法入參的方式，隻能通過Domain Service解決，見下文。

任何實體的行為隻能直接影響到本實體（和其子實體）

這個原則更多是一個確定代碼可讀性、可了解的原則，即任何實體的行為不能有“直接”的”副作用“，即直接修改其他的實體類。這麼做的好處是代碼讀下來不會産生意外。

另一個遵守的原因是可以降低未知的變更的風險。在一個系統裡一個實體對象的所有變更操作應該都是預期内的，如果一個實體能随意被外部直接修改的話，會增加代碼bug的風險。

▐ 領域服務（Domain Service）

在上文講到，領域服務其實也分很多種，在這裡根據上文總結出來三種常見的：

單對象政策型

這種領域對象主要面向的是單個實體對象的變更，但涉及到多個領域對象或外部依賴的一些規則。在上文中，EquipmentService即為此類：

變更的對象是Player的參數
讀取的是Player和Weapon的資料，可能還包括從外部讀取一些資料

在這種類型下，實體應該通過方法入參的方式傳入這種領域服務，然後通過Double Dispatch來反轉調用領域服務的方法，比如：

Player.equip(Weapon, EquipmentService) {
    EquipmentService.canEquip(this, Weapon);
}

為什麼這種情況下不能先調用領域服務，再調用實體對象的方法，進而減少實體對領域服務的入參型依賴呢？比如，下面這個方法是錯誤的：

boolean canEquip = EquipmentService.canEquip(Player, Weapon);
if (canEquip) {
    Player.equip(Weapon); // ❌，這種方法不可行，因為這個方法有不一緻的可能性
}

其錯誤的主要原因是缺少了領域服務入參會導緻方法有可能産生不一緻的情況。

跨對象事務型

當一個行為會直接修改多個實體時，不能再通過單一實體的方法作處理，而必須直接使用領域服務的方法來做操作。在這裡，領域服務更多的起到了跨對象事務的作用，確定多個實體的變更之間是有一緻性的。

在上文裡，雖然以下的代碼雖然可以跑到通，但是是不建議的：

public class Player {
    void attack(Monster, CombatService) {
        CombatService.performAttack(this, Monster); // ❌，不要這麼寫，會導緻副作用
    }
}

而我們真實調用應該直接調用CombatService的方法：

public void test() {
    //...
    combatService.performAttack(mage, orc);
}

這個原則也映射了4.1.5 的原則，即Player.attack會直接影響到Monster，但這個調用Monster又沒有感覺。

通用元件型

這種類型的領域服務更像ECS裡的System，提供了元件化的行為，但本身又不直接綁死在一種實體類上。具體案例可以參考上文中的MovementSystem實作。

▐ 政策對象（Domain Policy）

Policy或者Strategy設計模式是一個通用的設計模式，但是在DDD架構中會經常出現，其核心就是封裝領域規則。

一個Policy是一個無狀态的單例對象，通常需要至少2個方法：canApply 和一個業務方法。其中，canApply方法用來判斷一個Policy是否适用于目前的上下文，如果适用則調用方會去觸發業務方法。通常，為了降低一個Policy的可測試性和複雜度，Policy不應該直接操作對象，而是通過傳回計算後的值，在Domain Service裡對對象進行操作。

在上文案例裡，DamagePolicy隻負責計算應該受到的傷害，而不是直接對Monster造成傷害。這樣除了可測試外，還為未來的多Policy疊加計算做了準備。

除了本文裡靜态注入多個Policy以及手動排優先級之外，在日常開發中經常能見到通過Java的SPI機制或類SPI機制注冊Policy，以及通過不同的Priority方案對Policy進行排序，在這裡就不作太多的展開了。

加餐 - 副作用的處理方法 - 領域事件

在上文中，有一種類型的領域規則被我刻意忽略了，那就是”副作用“。一般的副作用發生在核心領域模型狀态變更後，同步或者異步對另一個對象的影響或行為。在這個案例裡，我們可以增加一個副作用規則：

當Monster的生命值降為0後，給Player獎勵經驗值

這種問題有很多種解法，比如直接把副作用寫在CombatService裡：

public class CombatService {
    public void performAttack(Player player, Monster monster) {
        // ...
        monster.takeDamage(damage);
        if (!monster.isAlive()) {
            player.receiveExp(10); // 收到經驗
        }
    }
}

但是這樣寫的問題是：很快CombatService的代碼就會變得很複雜，比如我們再加一個副作用：

當Player的exp達到100時，升一級

這時我們的代碼就會變成：

public class CombatService {
    public void performAttack(Player player, Monster monster) {
        // ...
        monster.takeDamage(damage);
        if (!monster.isAlive()) {
            player.receiveExp(10); // 收到經驗
            if (player.canLevelUp()) {
                player.levelUp(); // 更新
            }
        }
    }
}

如果再加上“更新後獎勵XXX”呢？“更新XXX排行”呢？依此類推，後續這種代碼将無法維護。是以我們需要介紹一下領域層最後一個概念：領域事件（Domain Event）。

▐ 領域事件介紹

領域事件是一個在領域裡發生了某些事後，希望領域裡其他對象能夠感覺到的通知機制。在上面的案例裡，代碼之是以會越來越複雜，其根本的原因是反應代碼（比如更新）直接和上面的事件觸發條件（比如收到經驗）直接耦合，而且這種耦合性是隐性的。領域事件的好處就是将這種隐性的副作用“顯性化”，通過一個顯性的事件，将事件觸發和事件處了解耦，最終起到代碼更清晰、擴充性更好的目的。

是以，領域事件是在DDD裡，比較推薦使用的跨實體“副作用”傳播機制。

▐ 領域事件實作

和消息隊列中間件不同的是，領域事件通常是立即執行的、在同一個程序内、可能是同步或異步。我們可以通過一個EventBus來實作程序内的通知機制，簡單實作如下：

// 實作者：瑜進 2019/11/28
public class EventBus {

    // 注冊器
    @Getter
    private final EventRegistry invokerRegistry = new EventRegistry(this);

    // 事件分發器
    private final EventDispatcher dispatcher = new EventDispatcher(ExecutorFactory.getDirectExecutor());

    // 異步事件分發器
    private final EventDispatcher asyncDispatcher = new EventDispatcher(ExecutorFactory.getThreadPoolExecutor());

    // 事件分發
    public boolean dispatch(Event event) {
        return dispatch(event, dispatcher);
    }

    // 異步事件分發
    public boolean dispatchAsync(Event event) {
        return dispatch(event, asyncDispatcher);
    }

    // 内部事件分發
    private boolean dispatch(Event event, EventDispatcher dispatcher) {
        checkEvent(event);
        // 1.擷取事件數組
        Set<Invoker> invokers = invokerRegistry.getInvokers(event);
        // 2.一個事件可以被監聽N次，不關心調用結果
        dispatcher.dispatch(event, invokers);
        return true;
    }

    // 事件總線注冊
    public void register(Object listener) {
        if (listener == null) {
            throw new IllegalArgumentException("listener can not be null!");
        }
        invokerRegistry.register(listener);
    }

    private void checkEvent(Event event) {
        if (event == null) {
            throw new IllegalArgumentException("event");
        }
        if (!(event instanceof Event)) {
            throw new IllegalArgumentException("Event type must by " + Event.class);
        }
    }
}

調用方式：

public class LevelUpEvent implements Event {
    private Player player;
}

public class LevelUpHandler {
    public void handle(Player player);
}

public class Player {
    public void receiveExp(int value) {
        this.exp += value;
        if (this.exp >= 100) {
            LevelUpEvent event = new LevelUpEvent(this);
            EventBus.dispatch(event);
            this.exp = 0;
        }
    }
}
@Test
public void test() {
    EventBus.register(new LevelUpHandler());
    player.setLevel(1);
    player.receiveExp(100);
    assertThat(player.getLevel()).equals(2);
}

▐ 目前領域事件的缺陷和展望

從上面代碼可以看出來，領域事件的很好的實施依賴EventBus、Dispatcher、Invoker這些屬于架構級别的支援。同時另一個問題是因為Entity不能直接依賴外部對象，是以EventBus目前隻能是一個全局的Singleton，而大家都應該知道全局Singleton對象很難被單測。這就容易導緻Entity對象無法被很容易的被完整單測覆寫全。

另一種解法是侵入Entity，對每個Entity增加一個List:

public class Player {
  List<Event> events;

  public void receiveExp(int value) {
        this.exp += value;
        if (this.exp >= 100) {
            LevelUpEvent event = new LevelUpEvent(this);
            events.add(event); // 把event加進去
            this.exp = 0;
        }
    }
}

@Test
public void test() {
    EventBus.register(new LevelUpHandler());
    player.setLevel(1);
    player.receiveExp(100);

    for(Event event: player.getEvents()) { // 在這裡顯性的dispatch事件
        EventBus.dispatch(event);
    }

    assertThat(player.getLevel()).equals(2);
}

但是能看出來這種解法不但會侵入實體本身，同時也需要比較啰嗦的顯性在調用方dispatch事件，也不是一個好的解決方案。

也許未來會有一個架構能讓我們既不依賴全局Singleton，也不需要顯性去處理事件，但目前的方案基本都有或多或少的缺陷，大家在使用中可以注意。

總結

在真實的業務邏輯裡，我們的領域模型或多或少的都有一定的“特殊性”，如果100%的要符合DDD規範可能會比較累，是以最主要的是梳理一個對象行為的影響面，然後作出設計決策，即：

是僅影響單一對象還是多個對象，
規則未來的拓展性、靈活性，
性能要求，
副作用的處理，等等

當然，很多時候一個好的設計是多種因素的取舍，需要大家有一定的積累，真正了解每個架構背後的邏輯和優缺點。一個好的架構師不是有一個正确答案，而是能從多個方案中選出一個最平衡的方案。

阿裡技術專家詳解DDD系列 第四講 - 領域層設計規範