殷浩詳解DDD：領域層設計規範

作者 | 殷浩
來源 | 阿里技術公眾號

在一個DDD架構設計中，領域層的設計合理性會直接影響整個架構的代碼結構以及應用層、基礎設施層的設計。但是領域層設計又是有挑戰的任務，特別是在一個業務邏輯相對複雜應用中，每一個業務規則是應該放在Entity、ValueObject 還是 DomainService是值得用心思考的，既要避免未來的擴展性差，又要確保不會過度設計導致複雜性。今天我用一個相對輕鬆易懂的領域做一個案例演示，但在實際業務應用中，無論是交易、營銷還是互動，都可以用類似的邏輯來實現。

一 初探龍與魔法的世界架構

1 背景和規則

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

基礎配置如下：

• 玩家（Player）可以是戰士（Fighter）、法師（Mage）、龍騎（Dragoon）
• 怪物（Monster）可以是獸人（Orc）、精靈（Elf）、龍（Dragon），怪物有血量
• 武器（Weapon）可以是劍（Sword）、法杖（Staff），武器有攻擊力

玩家可以裝備一個武器，武器攻擊可以是物理類型（0），火（1），冰（2）等，武器類型決定傷害類型。攻擊規則如下：

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

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);
    }
}

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

3 分析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 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）架構簡介

1 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案例的偽代碼如下：

public class Entity {
  public Vector position; // 此處Vector是一個Component, 指向的是MovementSystem.list裡的一個
}

public class MovementSystem {
  List< Vector> list;

  // System的行為
  public void update(float delta) {
    for(Vector pos : list) { // 這個loop直接走了CPU緩存，性能很高，同時可以用SIMD優化
      pos.x = pos.x + delta;
      pos.y = pos.y + delta;
    }
  }
}

@Test
public void test() {
  MovementSystem system = new MovementSystem();
  system.list = new List<>() { new Vector(0, 0) };
  Entity entity = new Entity(list.get(0));
  system.update(0.1);
  assertTrue(entity.position.x == 0.1);
}

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

2 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萬件不同類型、不同功能的物品，如果這些不同功能的物品都去單獨寫代碼，可能永遠都寫不完，但是通過數據驅動+組件化架構，所有物品的配置最終就是一張表，修改也極其簡單。這個也是組合勝於繼承原則的一次體現。

3 ECS的缺陷

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

三 基於DDD架構的一種解法

1 領域對象

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

實體類

在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或者繼承通用的父類，但是可以通過接口的方式對領域對象做組件化處理：

public 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代碼去處理，避免了重複勞動。

2 裝備行為

因為我們已經不會用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類，而不需要去改變原有的類。

3 攻擊行為

在上文中曾經有提起過，到底應該是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有可能會影響多個對象，所以不能直接通過參數注入的方式調用。

4 單元測試

@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));
}

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

5 移動系統

最後還有一種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領域層的設計成本。

1 實體類（Entity）

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

創建即一致

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

1）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 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); // 確保對象的有效性
}

2）使用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的風險。

2 領域服務（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);
}

這個原則也映射了“任何實體的行為只能直接影響到本實體（和其子實體）”的原則，即Player.attack會直接影響到Monster，但這個調用Monster又沒有感知。

通用組件型

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

3 策略對象（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）。

1 領域事件介紹

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

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

2 領域事件實現

和消息隊列中間件不同的是，領域事件通常是立即執行的、在同一個進程內、可能是同步或異步。我們可以通過一個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);
}

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

從上面代碼可以看出來，領域事件的很好的實施依賴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感興趣，或對本文有疑問的同學，歡迎和我交流討論，我的郵箱：[email protected]，也可以加我的釘釘號：luangm（殷浩）。

---

2021阿里雲峰會暨開發者大會

邀請函

數字時代，創新的時代。

萬千開發者匯聚智慧，啟迪夢想，不斷推動創新發生。

成立12年的阿里雲，始於開發者的理想，堅信開發者的力量。阿里雲，堅持用雲的力量讓開發者的創新更簡單，共同成就一個個數字新篇章。

2021年阿里雲開發者大會，一場開發者的頂級盛會，誠邀您的到來！

戳我，開啟你的專屬邀請函。