在一個(gè)DDD架構(gòu)設(shè)計(jì)中，領(lǐng)域?qū)拥脑O(shè)計(jì)合理性會(huì)直接影響整個(gè)架構(gòu)的代碼結(jié)構(gòu)以及應(yīng)用層、基礎(chǔ)設(shè)施層的設(shè)計(jì)。但是領(lǐng)域?qū)釉O(shè)計(jì)又是有挑戰(zhàn)的任務(wù)，特別是在一個(gè)業(yè)務(wù)邏輯相對(duì)復(fù)雜應(yīng)用中，每一個(gè)業(yè)務(wù)規(guī)則是應(yīng)該放在Entity、ValueObject 還是 DomainService是值得用心思考的，既要避免未來(lái)的擴(kuò)展性差，又要確保不會(huì)過(guò)度設(shè)計(jì)導(dǎo)致復(fù)雜性。今天我用一個(gè)相對(duì)輕松易懂的領(lǐng)域做一個(gè)案例演示，但在實(shí)際業(yè)務(wù)應(yīng)用中，無(wú)論是交易、營(yíng)銷還是互動(dòng)，都可以用類似的邏輯來(lái)實(shí)現(xiàn)。

一 初探龍與魔法的世界架構(gòu)

1 背景和規(guī)則

平日里看了好多嚴(yán)肅的業(yè)務(wù)代碼，今天找一個(gè)輕松的話題，如何用代碼實(shí)現(xiàn)一個(gè)龍與魔法的游戲世界的（極簡(jiǎn)）規(guī)則？

基礎(chǔ)配置如下：

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

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

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

2 OOP實(shí)現(xiàn)

對(duì)于熟悉Object-Oriented Programming的同學(xué)，一個(gè)比較簡(jiǎn)單的實(shí)現(xiàn)是通過(guò)類的繼承關(guān)系（此處省略部分非核心代碼）：

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 {}

而實(shí)現(xiàn)規(guī)則代碼如下：

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(); // 基礎(chǔ)規(guī)則
    }
}

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的物理防御規(guī)則
        } 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); // 龍騎傷害規(guī)則
        }
        // else no damage, 龍免疫力規(guī)則
    }
}

然后跑幾個(gè)單測(cè)：

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

以上代碼和單測(cè)都比較簡(jiǎn)單，不做多余的解釋了。

3 分析OOP代碼的設(shè)計(jì)缺陷

編程語(yǔ)言的強(qiáng)類型無(wú)法承載業(yè)務(wù)規(guī)則

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

• 戰(zhàn)士只能裝備劍
• 法師只能裝備法杖

這個(gè)規(guī)則在Java語(yǔ)言里無(wú)法通過(guò)強(qiáng)類型來(lái)實(shí)現(xiàn)，雖然Java有Variable Hiding（或者C#的new class variable），但實(shí)際上只是在子類上加了一個(gè)新變量，所以會(huì)導(dǎo)致以下的問(wèn)題：

@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); // 錯(cuò)誤了
}

在最后，雖然代碼感覺是setWeapon(Staff)，但實(shí)際上只修改了父類的變量，并沒有修改子類的變量，所以實(shí)際不生效，也不拋異常，但結(jié)果是錯(cuò)的。

當(dāng)然，可以在父類限制setter為protected，但這樣就限制了父類的API，極大的降低了靈活性，同時(shí)也違背了Liskov substitution principle，即一個(gè)父類必須要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); // 編譯不過(guò)，但從API層面上應(yīng)該開放可用
}

最后，如果規(guī)則增加一條：

• 戰(zhàn)士和法師都能裝備匕首（dagger）

BOOM，之前寫的強(qiáng)類型代碼都廢了，需要重構(gòu)。

對(duì)象繼承導(dǎo)致代碼強(qiáng)依賴父類邏輯，違反開閉原則Open-Closed Principle（OCP）

開閉原則（OCP）規(guī)定“對(duì)象應(yīng)該對(duì)于擴(kuò)展開放，對(duì)于修改封閉“，繼承雖然可以通過(guò)子類擴(kuò)展新的行為，但因?yàn)樽宇惪赡苤苯右蕾嚫割惖膶?shí)現(xiàn)，導(dǎo)致一個(gè)變更可能會(huì)影響所有對(duì)象。在這個(gè)例子里，如果增加任意一種類型的玩家、怪物或武器，或增加一種規(guī)則，都有可能需要修改從父類到子類的所有方法。

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

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

    public void receiveDamageBy(Weapon weapon, Player player) {
        this.health -= weapon.getDamage(); // 老的基礎(chǔ)規(guī)則
        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);
        }
        // 老的邏輯省略
    }
}

在一個(gè)復(fù)雜的軟件中為什么會(huì)建議“盡量”不要違背OCP？最核心的原因就是一個(gè)現(xiàn)有邏輯的變更可能會(huì)影響一些原有的代碼，導(dǎo)致一些無(wú)法預(yù)見的影響。這個(gè)風(fēng)險(xiǎn)只能通過(guò)完整的單元測(cè)試覆蓋來(lái)保障，但在實(shí)際開發(fā)中很難保障單測(cè)的覆蓋率。OCP的原則能盡可能的規(guī)避這種風(fēng)險(xiǎn)，當(dāng)新的行為只能通過(guò)新的字段/方法來(lái)實(shí)現(xiàn)時(shí)，老代碼的行為自然不會(huì)變。

繼承雖然能Open for extension，但很難做到Closed for modification。所以今天解決OCP的主要方法是通過(guò)
Composition-over-inheritance，即通過(guò)組合來(lái)做到擴(kuò)展性，而不是通過(guò)繼承。

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

在這個(gè)例子里，其實(shí)業(yè)務(wù)規(guī)則的邏輯到底應(yīng)該寫在哪里是有異議的：當(dāng)我們?nèi)タ匆粋€(gè)對(duì)象和另一個(gè)對(duì)象之間的交互時(shí)，到底是Player去攻擊Monster，還是Monster被Player攻擊？目前的代碼主要將邏輯寫在Monster的類中，主要考慮是Monster會(huì)受傷降低Health，但如果是Player拿著一把雙刃劍會(huì)同時(shí)傷害自己呢？是不是發(fā)現(xiàn)寫在Monster類里也有問(wèn)題？代碼寫在哪里的原則是什么？

多對(duì)象行為類似，導(dǎo)致代碼重復(fù)

當(dāng)我們有不同的對(duì)象，但又有相同或類似的行為時(shí)，OOP會(huì)不可避免的導(dǎo)致代碼的重復(fù)。在這個(gè)例子里，如果我們?nèi)ピ黾右粋€(gè)“可移動(dòng)”的行為，需要在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
    }
}

一個(gè)可能的解法是有個(gè)通用的父類：

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;

但如果再增加一個(gè)跳躍能力Jumpable呢？一個(gè)跑步能力Runnable呢？如果Player可以Move和Jump，Monster可以Move和Run，怎么處理繼承關(guān)系？要知道Java（以及絕大部分語(yǔ)言）是不支持多父類繼承的，所以只能通過(guò)重復(fù)代碼來(lái)實(shí)現(xiàn)。

問(wèn)題總結(jié)

在這個(gè)案例里雖然從直覺來(lái)看OOP的邏輯很簡(jiǎn)單，但如果你的業(yè)務(wù)比較復(fù)雜，未來(lái)會(huì)有大量的業(yè)務(wù)規(guī)則變更時(shí)，簡(jiǎn)單的OOP代碼會(huì)在后期變成復(fù)雜的一團(tuán)漿糊，邏輯分散在各地，缺少全局視角，各種規(guī)則的疊加會(huì)觸發(fā)bug。有沒有感覺似曾相識(shí)？對(duì)的，電商體系里的優(yōu)惠、交易等鏈路經(jīng)常會(huì)碰到類似的坑。而這類問(wèn)題的核心本質(zhì)在于：

• 業(yè)務(wù)規(guī)則的歸屬到底是對(duì)象的“行為”還是獨(dú)立的”規(guī)則對(duì)象“？
• 業(yè)務(wù)規(guī)則之間的關(guān)系如何處理？
• 通用“行為”應(yīng)該如何復(fù)用和維護(hù)？

在講DDD的解法前，我們先去看看一套游戲里最近比較火的架構(gòu)設(shè)計(jì)，Entity-Component-System（ECS）是如何實(shí)現(xiàn)的。

二 Entity-Component-System（ECS）架構(gòu)簡(jiǎn)介

1 ECS介紹

ECS架構(gòu)模式是其實(shí)是一個(gè)很老的游戲架構(gòu)設(shè)計(jì)，最早應(yīng)該能追溯到《地牢圍攻》的組件化設(shè)計(jì)，但最近因?yàn)閁nity的加入而開始變得流行（比如《守望先鋒》就是用的ECS）。要很快的理解ECS架構(gòu)的價(jià)值，我們需要理解一個(gè)游戲代碼的核心問(wèn)題：

• 性能：游戲必須要實(shí)現(xiàn)一個(gè)高的渲染率（60FPS），也就是說(shuō)整個(gè)游戲世界需要在1/60s（大概16ms）內(nèi)完整更新一次（包括物理引擎、游戲狀態(tài)、渲染、AI等）。而在一個(gè)游戲中，通常有大量的（萬(wàn)級(jí)、十萬(wàn)級(jí)）游戲?qū)ο笮枰聽顟B(tài)，除了渲染可以依賴GPU之外，其他的邏輯都需要由CPU完成，甚至絕大部分只能由單線程完成，導(dǎo)致絕大部分時(shí)間復(fù)雜場(chǎng)景下CPU（主要是內(nèi)存到CPU的帶寬）會(huì)成為瓶頸。在CPU單核速度幾乎不再增加的時(shí)代，如何能讓CPU處理的效率提升，是提升游戲性能的核心。
• 代碼組織：如同第一章講的案例一樣，當(dāng)我們用傳統(tǒng)OOP的模式進(jìn)行游戲開發(fā)時(shí)，很容易就會(huì)陷入代碼組織上的問(wèn)題，最終導(dǎo)致代碼難以閱讀，維護(hù)和優(yōu)化。
• 可擴(kuò)展性：這個(gè)跟上一條類似，但更多的是游戲的特性導(dǎo)致：需要快速更新，加入新的元素。一個(gè)游戲的架構(gòu)需要能通過(guò)低代碼、甚至0代碼的方式增加游戲元素，從而通過(guò)快速更新而留住用戶。如果每次變更都需要開發(fā)新的代碼，測(cè)試，然后讓用戶重新下載客戶端，可想而知這種游戲很難在現(xiàn)在的競(jìng)爭(zhēng)環(huán)境下活下來(lái)。

而ECS架構(gòu)能很好的解決上面的幾個(gè)問(wèn)題，ECS架構(gòu)主要分為：

• Entity：用來(lái)代表任何一個(gè)游戲?qū)ο螅窃贓CS里一個(gè)Entity最重要的僅僅是他的EntityID，一個(gè)Entity里包含多個(gè)Component
• Component：是真正的數(shù)據(jù)，ECS架構(gòu)把一個(gè)個(gè)的實(shí)體對(duì)象拆分為更加細(xì)化的組件，比如位置、素材、狀態(tài)等，也就是說(shuō)一個(gè)Entity實(shí)際上只是一個(gè)Bag of Components。
• System（或者ComponentSystem，組件系統(tǒng)）：是真正的行為，一個(gè)游戲里可以有很多個(gè)不同的組件系統(tǒng)，每個(gè)組件系統(tǒng)都只負(fù)責(zé)一件事，可以依次處理大量的相同組件，而不需要去理解具體的Entity。所以一個(gè)ComponentSystem理論上可以有更加高效的組件處理效率，甚至可以實(shí)現(xiàn)并行處理，從而提升CPU利用率。

ECS的一些核心性能優(yōu)化包括將同類型組件放在同一個(gè)Array中，然后Entity僅保留到各自組件的pointer，這樣能更好的利用CPU的緩存，減少數(shù)據(jù)的加載成本，以及SIMD的優(yōu)化等。

一個(gè)ECS案例的偽代碼如下：

public class Entity {
  public Vector position; // 此處Vector是一個(gè)Component, 指向的是MovementSystem.list里的一個(gè)
}

public class MovementSystem {
  List< Vector> list;

  // System的行為
  public void update(float delta) {
    for(Vector pos : list) { // 這個(gè)loop直接走了CPU緩存，性能很高，同時(shí)可以用SIMD優(yōu)化
      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架構(gòu)的，感興趣的同學(xué)可以搜索Entity-Component-System或者看看Unity的ECS文檔等。

2 ECS架構(gòu)分析

重新回來(lái)分析ECS，其實(shí)它的本源還是幾個(gè)很老的概念：

組件化

在軟件系統(tǒng)里，我們通常將復(fù)雜的大系統(tǒng)拆分為獨(dú)立的組件，來(lái)降低復(fù)雜度。比如網(wǎng)頁(yè)里通過(guò)前端組件化降低重復(fù)開發(fā)成本，微服務(wù)架構(gòu)通過(guò)服務(wù)和數(shù)據(jù)庫(kù)的拆分降低服務(wù)復(fù)雜度和系統(tǒng)影響面等。但是ECS架構(gòu)把這個(gè)走到了極致，即每個(gè)對(duì)象內(nèi)部都實(shí)現(xiàn)了組件化。通過(guò)將一個(gè)游戲?qū)ο蟮臄?shù)據(jù)和行為拆分為多個(gè)組件和組件系統(tǒng)，能實(shí)現(xiàn)組件的高度復(fù)用性，降低重復(fù)開發(fā)成本。

行為抽離

這個(gè)在游戲系統(tǒng)里有個(gè)比較明顯的優(yōu)勢(shì)。如果按照OOP的方式，一個(gè)游戲?qū)ο罄锟赡軙?huì)包括移動(dòng)代碼、戰(zhàn)斗代碼、渲染代碼、AI代碼等，如果都放在一個(gè)類里會(huì)很長(zhǎng)，且很難去維護(hù)。通過(guò)將通用邏輯抽離出來(lái)為單獨(dú)的System類，可以明顯提升代碼的可讀性。另一個(gè)好處則是抽離了一些和對(duì)象代碼無(wú)關(guān)的依賴，比如上文的delta，這個(gè)delta如果是放在Entity的update方法，則需要作為入?yún)⒆⑷?，而放在System里則可以統(tǒng)一管理。在第一章的有個(gè)問(wèn)題，到底是應(yīng)該P(yáng)layer.attack(monster) 還是 Monster.receiveDamage(Weapon, Player)。在ECS里這個(gè)問(wèn)題就變得很簡(jiǎn)單，放在CombatSystem里就可以了。

數(shù)據(jù)驅(qū)動(dòng)

即一個(gè)對(duì)象的行為不是寫死的而是通過(guò)其參數(shù)決定，通過(guò)參數(shù)的動(dòng)態(tài)修改，就可以快速改變一個(gè)對(duì)象的具體行為。在ECS的游戲架構(gòu)里，通過(guò)給Entity注冊(cè)相應(yīng)的Component，以及改變Component的具體參數(shù)的組合，就可以改變一個(gè)對(duì)象的行為和玩法，比如創(chuàng)建一個(gè)水壺+爆炸屬性就變成了“爆炸水壺”、給一個(gè)自行車加上風(fēng)魔法就變成了飛車等。在有些Rougelike游戲中，可能有超過(guò)1萬(wàn)件不同類型、不同功能的物品，如果這些不同功能的物品都去單獨(dú)寫代碼，可能永遠(yuǎn)都寫不完，但是通過(guò)數(shù)據(jù)驅(qū)動(dòng)+組件化架構(gòu)，所有物品的配置最終就是一張表，修改也極其簡(jiǎn)單。這個(gè)也是組合勝于繼承原則的一次體現(xiàn)。

3 ECS的缺陷

雖然ECS在游戲界已經(jīng)開始嶄露頭角，我發(fā)現(xiàn)ECS架構(gòu)目前還沒有在哪個(gè)大型商業(yè)應(yīng)用中被使用過(guò)。原因可能很多，包括ECS比較新大家還不了解、缺少商業(yè)成熟可用的框架、程序員們還不夠能適應(yīng)從寫邏輯腳本到寫組件的思維轉(zhuǎn)變等，但我認(rèn)為其最大的一個(gè)問(wèn)題是ECS為了提升性能，強(qiáng)調(diào)了數(shù)據(jù)/狀態(tài)（State）和行為（Behaivor）分離，并且為了降低GC成本，直接操作數(shù)據(jù)，走到了一個(gè)極端。而在商業(yè)應(yīng)用中，數(shù)據(jù)的正確性、一致性和健壯性應(yīng)該是最高的優(yōu)先級(jí)，而性能只是錦上添花的東西，所以ECS很難在商業(yè)場(chǎng)景里帶來(lái)特別大的好處。但這不代表我們不能借鑒一些ECS的突破性思維，包括組件化、跨對(duì)象行為的抽離、以及數(shù)據(jù)驅(qū)動(dòng)模式，而這些在DDD里也能很好的用起來(lái)。

三 基于DDD架構(gòu)的一種解法

1 領(lǐng)域?qū)ο?/strong>

回到我們?cè)瓉?lái)的問(wèn)題域上面，我們從領(lǐng)域?qū)硬鸱忠幌赂鞣N對(duì)象：

實(shí)體類

在DDD里，實(shí)體類包含ID和內(nèi)部狀態(tài)，在這個(gè)案例里實(shí)體類包含Player、Monster和Weapon。Weapon被設(shè)計(jì)成實(shí)體類是因?yàn)閮砂淹腤eapon應(yīng)該可以同時(shí)存在，所以必須要有ID來(lái)區(qū)分，同時(shí)未來(lái)也可以預(yù)期Weapon會(huì)包含一些狀態(tài)，比如升級(jí)、臨時(shí)的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
}

在這個(gè)簡(jiǎn)單的案例里，我們可以利用enum的PlayerClass、MonsterClass來(lái)代替繼承關(guān)系，后續(xù)也可以利用Type Object設(shè)計(jì)模式來(lái)做到數(shù)據(jù)驅(qū)動(dòng)。

Note 1: 因?yàn)?Weapon 是實(shí)體類，但是Weapon能獨(dú)立存在，Player不是聚合根，所以Player只能保存WeaponId，而不能直接指向Weapon。

值對(duì)象的組件化

在前面的ECS架構(gòu)里，有個(gè)MovementSystem的概念是可以復(fù)用的，雖然不應(yīng)該直接去操作Component或者繼承通用的父類，但是可以通過(guò)接口的方式對(duì)領(lǐng)域?qū)ο笞鼋M件化處理：

public interface Movable {
    // 相當(dāng)于組件
    Transform getPosition();
    Vector getVelocity();

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

// 具體實(shí)現(xiàn)
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;
}

注意兩點(diǎn)：

• Moveable的接口沒有Setter。一個(gè)Entity的規(guī)則是不能直接變更其屬性，必須通過(guò)Entity的方法去對(duì)內(nèi)部狀態(tài)做變更。這樣能保證數(shù)據(jù)的一致性。
• 抽象Movable的好處是如同ECS一樣，一些特別通用的行為（如在大地圖里移動(dòng)）可以通過(guò)統(tǒng)一的System代碼去處理，避免了重復(fù)勞動(dòng)。

2 裝備行為

因?yàn)槲覀円呀?jīng)不會(huì)用Player的子類來(lái)決定什么樣的Weapon可以裝備，所以這段邏輯應(yīng)該被拆分到一個(gè)單獨(dú)的類里。這種類在DDD里被叫做領(lǐng)域服務(wù)（Domain Service）。

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

在DDD里，一個(gè)Entity不應(yīng)該直接參考另一個(gè)Entity或服務(wù)，也就是說(shuō)以下的代碼是錯(cuò)誤的：

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

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

這里的問(wèn)題是Entity只能保留自己的狀態(tài)（或非聚合根的對(duì)象）。任何其他的對(duì)象，無(wú)論是否通過(guò)依賴注入的方式弄進(jìn)來(lái)，都會(huì)破壞Entity的Invariance，并且還難以單測(cè)。

正確的引用方式是通過(guò)方法參數(shù)引入（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);
        }
    }
}

在這里，無(wú)論是Weapon還是EquipmentService都是通過(guò)方法參數(shù)傳入，確保不會(huì)污染Player的自有狀態(tài)。

Double Dispatch是一個(gè)使用Domain Service經(jīng)常會(huì)用到的方法，類似于調(diào)用反轉(zhuǎn)。

然后在EquipmentService里實(shí)現(xiàn)相關(guān)的邏輯判斷，這里我們用了另一個(gè)常用的Strategy（或者叫Policy）設(shè)計(jì)模式：

public class EquipmentServiceImpl implements EquipmentService {
    private EquipmentManager equipmentManager; 

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

// 策略優(yōu)先級(jí)管理
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;
    }
}

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

這樣設(shè)計(jì)的最大好處是未來(lái)的規(guī)則增加只需要添加新的Policy類，而不需要去改變?cè)械念悺?/span>

3 攻擊行為

在上文中曾經(jīng)有提起過(guò)，到底應(yīng)該是Player.attack(Monster)還是Monster.receiveDamage(Weapon, Player)？在DDD里，因?yàn)檫@個(gè)行為可能會(huì)影響到Player、Monster和Weapon，所以屬于跨實(shí)體的業(yè)務(wù)邏輯。在這種情況下需要通過(guò)一個(gè)第三方的領(lǐng)域服務(wù)（Domain Service）來(lái)完成。

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）在領(lǐng)域服務(wù)里變更Monster
        }
        // 省略掉Player和Weapon可能受到的影響
    }
}

同樣的在這個(gè)案例里，可以通過(guò)Strategy設(shè)計(jì)模式來(lái)解決damage的計(jì)算問(wèn)題：

// 策略優(yōu)先級(jí)管理
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領(lǐng)域服務(wù)和3.2的EquipmentService領(lǐng)域服務(wù)，雖然都是領(lǐng)域服務(wù)，但實(shí)質(zhì)上有很大的差異。上文的EquipmentService更多的是提供只讀策略，且只會(huì)影響單個(gè)對(duì)象，所以可以在Player.equip方法上通過(guò)參數(shù)注入。但是CombatService有可能會(huì)影響多個(gè)對(duì)象，所以不能直接通過(guò)參數(shù)注入的方式調(diào)用。

4 單元測(cè)試

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

具體的代碼比較簡(jiǎn)單，解釋省略。

5 移動(dòng)系統(tǒng)

最后還有一種Domain Service，通過(guò)組件化，我們其實(shí)可以實(shí)現(xiàn)ECS一樣的System，來(lái)降低一些重復(fù)性的代碼：

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

單測(cè)：

@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就是一個(gè)相對(duì)獨(dú)立的Domain Service，通過(guò)對(duì)Movable的組件化，實(shí)現(xiàn)了類似代碼的集中化、以及一些通用依賴/配置的中心化（如X、Y邊界等）。

四 DDD領(lǐng)域?qū)拥囊恍┰O(shè)計(jì)規(guī)范

上面我主要針對(duì)同一個(gè)例子對(duì)比了OOP、ECS和DDD的3種實(shí)現(xiàn)，比較如下：

• 基于繼承關(guān)系的OOP代碼：OOP的代碼最好寫，也最容易理解，所有的規(guī)則代碼都寫在對(duì)象里，但是當(dāng)領(lǐng)域規(guī)則變得越來(lái)越復(fù)雜時(shí)，其結(jié)構(gòu)會(huì)限制它的發(fā)展。新的規(guī)則有可能會(huì)導(dǎo)致代碼的整體重構(gòu)。
• 基于組件化的ECS代碼：ECS代碼有最高的靈活性、可復(fù)用性、及性能，但極具弱化了實(shí)體類的內(nèi)聚，所有的業(yè)務(wù)邏輯都寫在了服務(wù)里，會(huì)導(dǎo)致業(yè)務(wù)的一致性無(wú)法保障，對(duì)商業(yè)系統(tǒng)會(huì)有較大的影響。
• 基于領(lǐng)域?qū)ο?+ 領(lǐng)域服務(wù)的DDD架構(gòu)：DDD的規(guī)則其實(shí)最復(fù)雜，同時(shí)要考慮到實(shí)體類的內(nèi)聚和保證不變性（Invariants），也要考慮跨對(duì)象規(guī)則代碼的歸屬，甚至要考慮到具體領(lǐng)域服務(wù)的調(diào)用方式，理解成本比較高。

所以下面，我會(huì)盡量通過(guò)一些設(shè)計(jì)規(guī)范，來(lái)降低DDD領(lǐng)域?qū)拥脑O(shè)計(jì)成本。

1 實(shí)體類（Entity）

大多數(shù)DDD架構(gòu)的核心都是實(shí)體類，實(shí)體類包含了一個(gè)領(lǐng)域里的狀態(tài)、以及對(duì)狀態(tài)的直接操作。Entity最重要的設(shè)計(jì)原則是保證實(shí)體的不變性（Invariants），也就是說(shuō)要確保無(wú)論外部怎么操作，一個(gè)實(shí)體內(nèi)部的屬性都不能出現(xiàn)相互沖突，狀態(tài)不一致的情況。所以幾個(gè)設(shè)計(jì)原則如下：

創(chuàng)建即一致

在貧血模型里，通常見到的代碼是一個(gè)模型通過(guò)手動(dòng)new出來(lái)之后，由調(diào)用方一個(gè)參數(shù)一個(gè)參數(shù)的賦值，這就很容易產(chǎn)生遺漏，導(dǎo)致實(shí)體狀態(tài)不一致。所以DDD里實(shí)體創(chuàng)建的方法有兩種：

1）constructor參數(shù)要包含所有必要屬性，或者在constructor里有合理的默認(rèn)值

比如，賬號(hào)的創(chuàng)建：

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

@Test
public void test() {
    Account account = new Account();
    account.setAmount(100L);
    TransferService.transfer(account); // 報(bào)錯(cuò)了，因?yàn)锳ccount缺少必要的AccountNumber
}

如果缺少一個(gè)強(qiáng)校驗(yàn)的constructor，就無(wú)法保障創(chuàng)建的實(shí)體的一致性。所以需要增加一個(gè)強(qiáng)校驗(yàn)的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); // 確保對(duì)象的有效性
}

2）使用Factory模式來(lái)降低調(diào)用方復(fù)雜度

另一種方法是通過(guò)Factory模式來(lái)創(chuàng)建對(duì)象，降低一些重復(fù)性的入?yún)?。比如?/span>

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

通過(guò)傳入一個(gè)已經(jīng)存在的Prototype，可以快速的創(chuàng)建新的實(shí)體。還有一些其他的如Builder等設(shè)計(jì)模式就不一一指出了。

盡量避免public setter

一個(gè)最容易導(dǎo)致不一致性的原因是實(shí)體暴露了public的setter方法，特別是set單一參數(shù)會(huì)導(dǎo)致狀態(tài)不一致的情況。比如，一個(gè)訂單可能包含訂單狀態(tài)（下單、已支付、已發(fā)貨、已收貨）、支付單、物流單等子實(shí)體，如果一個(gè)調(diào)用方能隨意去set訂單狀態(tài)，就有可能導(dǎo)致訂單狀態(tài)和子實(shí)體匹配不上，導(dǎo)致業(yè)務(wù)流程走不通的情況。所以在實(shí)體里，需要通過(guò)行為方法來(lái)修改內(nèi)部狀態(tài)：

@Data @Setter(AccessLevel.PRIVATE) // 確保不生成public setter
public class Order {
    private int status; // 0 - 創(chuàng)建，1 - 支付，2 - 發(fā)貨，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);
    }
}

【建議】在有些簡(jiǎn)單場(chǎng)景里，有時(shí)候確實(shí)可以比較隨意的設(shè)置一個(gè)值而不會(huì)導(dǎo)致不一致性，也建議將方法名重新寫為比較“行為化”的命名，會(huì)增強(qiáng)其語(yǔ)意。比如setPosition(x, y)可以叫做moveTo(x, y)，setAddress可以叫做assignAddress等。

通過(guò)聚合根保證主子實(shí)體的一致性

在稍微復(fù)雜一點(diǎn)的領(lǐng)域里，通常主實(shí)體會(huì)包含子實(shí)體，這時(shí)候主實(shí)體就需要起到聚合根的作用，即：

• 子實(shí)體不能單獨(dú)存在，只能通過(guò)聚合根的方法獲取到。任何外部的對(duì)象都不能直接保留子實(shí)體的引用
• 子實(shí)體沒有獨(dú)立的Repository，不可以單獨(dú)保存和取出，必須要通過(guò)聚合根的Repository實(shí)例化
• 子實(shí)體可以單獨(dú)修改自身狀態(tài)，但是多個(gè)子實(shí)體之間的狀態(tài)一致性需要聚合根來(lái)保障

常見的電商域中聚合的案例如主子訂單模型、商品/SKU模型、跨子訂單優(yōu)惠、跨店優(yōu)惠模型等。很多聚合根和Repository的設(shè)計(jì)規(guī)范在我前面一篇關(guān)于Repository的文章中已經(jīng)詳細(xì)解釋過(guò)，可以拿來(lái)參考。

不可以強(qiáng)依賴其他聚合根實(shí)體或領(lǐng)域服務(wù)

一個(gè)實(shí)體的原則是高內(nèi)聚、低耦合，即一個(gè)實(shí)體類不能直接在內(nèi)部直接依賴一個(gè)外部的實(shí)體或服務(wù)。這個(gè)原則和絕大多數(shù)ORM框架都有比較嚴(yán)重的沖突，所以是一個(gè)在開發(fā)過(guò)程中需要特別注意的。這個(gè)原則的必要原因包括：對(duì)外部對(duì)象的依賴性會(huì)直接導(dǎo)致實(shí)體無(wú)法被單測(cè)；以及一個(gè)實(shí)體無(wú)法保證外部實(shí)體變更后不會(huì)影響本實(shí)體的一致性和正確性。

所以，正確的對(duì)外部依賴的方法有兩種：

• 只保存外部實(shí)體的ID：這里我再次強(qiáng)烈建議使用強(qiáng)類型的ID對(duì)象，而不是Long型ID。強(qiáng)類型的ID對(duì)象不單單能自我包含驗(yàn)證代碼，保證ID值的正確性，同時(shí)還能確保各種入?yún)⒉粫?huì)因?yàn)閰?shù)順序變化而出bug。具體可以參考我的Domain Primitive文章。
• 針對(duì)于“無(wú)副作用”的外部依賴，通過(guò)方法入?yún)⒌姆绞絺魅?。比如上文中的equip(Weapon，EquipmentService）方法。

如果方法對(duì)外部依賴有副作用，不能通過(guò)方法入?yún)⒌姆绞?，只能通過(guò)Domain Service解決，見下文。

任何實(shí)體的行為只能直接影響到本實(shí)體（和其子實(shí)體）

這個(gè)原則更多是一個(gè)確保代碼可讀性、可理解的原則，即任何實(shí)體的行為不能有“直接”的”副作用“，即直接修改其他的實(shí)體類。這么做的好處是代碼讀下來(lái)不會(huì)產(chǎn)生意外。

另一個(gè)遵守的原因是可以降低未知的變更的風(fēng)險(xiǎn)。在一個(gè)系統(tǒng)里一個(gè)實(shí)體對(duì)象的所有變更操作應(yīng)該都是預(yù)期內(nèi)的，如果一個(gè)實(shí)體能隨意被外部直接修改的話，會(huì)增加代碼bug的風(fēng)險(xiǎn)。

2 領(lǐng)域服務(wù)（Domain Service）

在上文講到，領(lǐng)域服務(wù)其實(shí)也分很多種，在這里根據(jù)上文總結(jié)出來(lái)三種常見的：

單對(duì)象策略型

這種領(lǐng)域?qū)ο笾饕嫦虻氖菃蝹€(gè)實(shí)體對(duì)象的變更，但涉及到多個(gè)領(lǐng)域?qū)ο蠡蛲獠恳蕾嚨囊恍┮?guī)則。在上文中，EquipmentService即為此類：

• 變更的對(duì)象是Player的參數(shù)
• 讀取的是Player和Weapon的數(shù)據(jù)，可能還包括從外部讀取一些數(shù)據(jù)

在這種類型下，實(shí)體應(yīng)該通過(guò)方法入?yún)⒌姆绞絺魅脒@種領(lǐng)域服務(wù)，然后通過(guò)Double Dispatch來(lái)反轉(zhuǎn)調(diào)用領(lǐng)域服務(wù)的方法，比如：

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

為什么這種情況下不能先調(diào)用領(lǐng)域服務(wù)，再調(diào)用實(shí)體對(duì)象的方法，從而減少實(shí)體對(duì)領(lǐng)域服務(wù)的入?yún)⑿鸵蕾嚹?？比如，下面這個(gè)方法是錯(cuò)誤的：

boolean canEquip = EquipmentService.canEquip(Player, Weapon);
if (canEquip) {
    Player.equip(Weapon); // ?，這種方法不可行，因?yàn)檫@個(gè)方法有不一致的可能性
}

其錯(cuò)誤的主要原因是缺少了領(lǐng)域服務(wù)入?yún)?huì)導(dǎo)致方法有可能產(chǎn)生不一致的情況。

跨對(duì)象事務(wù)型

當(dāng)一個(gè)行為會(huì)直接修改多個(gè)實(shí)體時(shí)，不能再通過(guò)單一實(shí)體的方法作處理，而必須直接使用領(lǐng)域服務(wù)的方法來(lái)做操作。在這里，領(lǐng)域服務(wù)更多的起到了跨對(duì)象事務(wù)的作用，確保多個(gè)實(shí)體的變更之間是有一致性的。

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

public class Player {
    void attack(Monster, CombatService) {
        CombatService.performAttack(this, Monster); // ?，不要這么寫，會(huì)導(dǎo)致副作用
    }
}

而我們真實(shí)調(diào)用應(yīng)該直接調(diào)用CombatService的方法：

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

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

通用組件型

這種類型的領(lǐng)域服務(wù)更像ECS里的System，提供了組件化的行為，但本身又不直接綁死在一種實(shí)體類上。具體案例可以參考上文中的MovementSystem實(shí)現(xiàn)。

3 策略對(duì)象（Domain Policy）

Policy或者Strategy設(shè)計(jì)模式是一個(gè)通用的設(shè)計(jì)模式，但是在DDD架構(gòu)中會(huì)經(jīng)常出現(xiàn)，其核心就是封裝領(lǐng)域規(guī)則。

一個(gè)Policy是一個(gè)無(wú)狀態(tài)的單例對(duì)象，通常需要至少2個(gè)方法：canApply 和 一個(gè)業(yè)務(wù)方法。其中，canApply方法用來(lái)判斷一個(gè)Policy是否適用于當(dāng)前的上下文，如果適用則調(diào)用方會(huì)去觸發(fā)業(yè)務(wù)方法。通常，為了降低一個(gè)Policy的可測(cè)試性和復(fù)雜度，Policy不應(yīng)該直接操作對(duì)象，而是通過(guò)返回計(jì)算后的值，在Domain Service里對(duì)對(duì)象進(jìn)行操作。

在上文案例里，DamagePolicy只負(fù)責(zé)計(jì)算應(yīng)該受到的傷害，而不是直接對(duì)Monster造成傷害。這樣除了可測(cè)試外，還為未來(lái)的多Policy疊加計(jì)算做了準(zhǔn)備。

除了本文里靜態(tài)注入多個(gè)Policy以及手動(dòng)排優(yōu)先級(jí)之外，在日常開發(fā)中經(jīng)常能見到通過(guò)Java的SPI機(jī)制或類SPI機(jī)制注冊(cè)Policy，以及通過(guò)不同的Priority方案對(duì)Policy進(jìn)行排序，在這里就不作太多的展開了。

五 副作用的處理方法 - 領(lǐng)域事件

在上文中，有一種類型的領(lǐng)域規(guī)則被我刻意忽略了，那就是”副作用“。一般的副作用發(fā)生在核心領(lǐng)域模型狀態(tài)變更后，同步或者異步對(duì)另一個(gè)對(duì)象的影響或行為。在這個(gè)案例里，我們可以增加一個(gè)副作用規(guī)則：

當(dāng)Monster的生命值降為0后，給Player獎(jiǎng)勵(lì)經(jīng)驗(yàn)值

這種問(wèn)題有很多種解法，比如直接把副作用寫在CombatService里：

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

但是這樣寫的問(wèn)題是：很快CombatService的代碼就會(huì)變得很復(fù)雜，比如我們?cè)偌右粋€(gè)副作用：

當(dāng)Player的exp達(dá)到100時(shí)，升一級(jí)

這時(shí)我們的代碼就會(huì)變成：

public class CombatService {
    public void performAttack(Player player, Monster monster) {
        // ...
        monster.takeDamage(damage);
        if (!monster.isAlive()) {
            player.receiveExp(10); // 收到經(jīng)驗(yàn)
            if (player.canLevelUp()) {
                player.levelUp(); // 升級(jí)
            }
        }
    }
}

如果再加上“升級(jí)后獎(jiǎng)勵(lì)XXX”呢？“更新XXX排行”呢？依此類推，后續(xù)這種代碼將無(wú)法維護(hù)。所以我們需要介紹一下領(lǐng)域?qū)幼詈笠粋€(gè)概念：領(lǐng)域事件（Domain Event）。

1 領(lǐng)域事件介紹

領(lǐng)域事件是一個(gè)在領(lǐng)域里發(fā)生了某些事后，希望領(lǐng)域里其他對(duì)象能夠感知到的通知機(jī)制。在上面的案例里，代碼之所以會(huì)越來(lái)越復(fù)雜，其根本的原因是反應(yīng)代碼（比如升級(jí)）直接和上面的事件觸發(fā)條件（比如收到經(jīng)驗(yàn)）直接耦合，而且這種耦合性是隱性的。領(lǐng)域事件的好處就是將這種隱性的副作用“顯性化”，通過(guò)一個(gè)顯性的事件，將事件觸發(fā)和事件處理解耦，最終起到代碼更清晰、擴(kuò)展性更好的目的。

所以，領(lǐng)域事件是在DDD里，比較推薦使用的跨實(shí)體“副作用”傳播機(jī)制。

2 領(lǐng)域事件實(shí)現(xiàn)

和消息隊(duì)列中間件不同的是，領(lǐng)域事件通常是立即執(zhí)行的、在同一個(gè)進(jìn)程內(nèi)、可能是同步或異步。我們可以通過(guò)一個(gè)EventBus來(lái)實(shí)現(xiàn)進(jìn)程內(nèi)的通知機(jī)制，簡(jiǎn)單實(shí)現(xiàn)如下：

// 實(shí)現(xiàn)者：瑜進(jìn) 2019/11/28
public class EventBus {

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

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

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

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

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

    // 內(nèi)部事件分發(fā)
    private boolean dispatch(Event event, EventDispatcher dispatcher) {
        checkEvent(event);
        // 1.獲取事件數(shù)組
        Set< Invoker> invokers = invokerRegistry.getInvokers(event);
        // 2.一個(gè)事件可以被監(jiān)聽N次，不關(guān)心調(diào)用結(jié)果
        dispatcher.dispatch(event, invokers);
        return true;
    }

    // 事件總線注冊(cè)
    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);
        }
    }
}

調(diào)用方式：

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 目前領(lǐng)域事件的缺陷和展望

從上面代碼可以看出來(lái)，領(lǐng)域事件的很好的實(shí)施依賴EventBus、Dispatcher、Invoker這些屬于框架級(jí)別的支持。同時(shí)另一個(gè)問(wèn)題是因?yàn)镋ntity不能直接依賴外部對(duì)象，所以EventBus目前只能是一個(gè)全局的Singleton，而大家都應(yīng)該知道全局Singleton對(duì)象很難被單測(cè)。這就容易導(dǎo)致Entity對(duì)象無(wú)法被很容易的被完整單測(cè)覆蓋全。

另一種解法是侵入Entity，對(duì)每個(gè)Entity增加一個(gè)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加進(jìn)去
            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);
}

但是能看出來(lái)這種解法不但會(huì)侵入實(shí)體本身，同時(shí)也需要比較啰嗦的顯性在調(diào)用方dispatch事件，也不是一個(gè)好的解決方案。

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

六 總結(jié)

在真實(shí)的業(yè)務(wù)邏輯里，我們的領(lǐng)域模型或多或少的都有一定的“特殊性”，如果100%的要符合DDD規(guī)范可能會(huì)比較累，所以最主要的是梳理一個(gè)對(duì)象行為的影響面，然后作出設(shè)計(jì)決策，即：

• 是僅影響單一對(duì)象還是多個(gè)對(duì)象
• 規(guī)則未來(lái)的拓展性、靈活性
• 性能要求
• 副作用的處理，等等

當(dāng)然，很多時(shí)候一個(gè)好的設(shè)計(jì)是多種因素的取舍，需要大家有一定的積累，真正理解每個(gè)架構(gòu)背后的邏輯和優(yōu)缺點(diǎn)。一個(gè)好的架構(gòu)師不是有一個(gè)正確答案，而是能從多個(gè)方案中選出一個(gè)最平衡的方案。

作者 | 殷浩

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。