DDD 系列第四講：領域層設計規範

▐ 背景和規則

基礎配置如下：

攻擊規則如下：

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

▐ OOP 實現

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

而實現規則代碼如下：

 1public class Player {
 2    public void attack(Monster monster) {
 3        monster.receiveDamageBy(weapon, this);
 4    }
 5}
 6public class Monster {
 7    public void receiveDamageBy(Weapon weapon, Player player) {
 8        this.health -= weapon.getDamage(); // 基礎規則
 9    }
10}
11public class Orc extends Monster {
12    @Override
13    public void receiveDamageBy(Weapon weapon, Player player) {
14        if (weapon.getDamageType() == 0) {
15            this.setHealth(this.getHealth() - weapon.getDamage() / 2); // Orc的物理防禦規則
16        } else {
17            super.receiveDamageBy(weapon, player);
18        }
19    }
20}
21public class Dragon extends Monster {
22    @Override
23    public void receiveDamageBy(Weapon weapon, Player player) {
24        if (player instanceof Dragoon) {
25            this.setHealth(this.getHealth() - weapon.getDamage() * 2); // 龍騎傷害規則
26        }
27        // else no damage, 龍免疫力規則
28    }
29}

然後跑幾個單測：

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

▐ 分析 OOP 代碼的設計缺陷

編程語言的強類型無法承載業務規則

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

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

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

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

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

 1@Data
 2public abstract class Player {
 3    @Setter(AccessLevel.PROTECTED)
 4    private Weapon weapon;
 5}
 6@Test
 7public void testCastEquip() {
 8    Fighter fighter = new Fighter("Hero");
 9    Sword sword = new Sword("Sword", 10);
10    fighter.setWeapon(sword);
11    Player player = fighter;
12    Staff staff = new Staff("Staff", 10);
13    player.setWeapon(staff); // 編譯不過，但從API層面上應該開放可用
14}

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

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

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

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

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

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

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

 1public class Monster {
 2    public void receiveDamageBy(Weapon weapon, Player player) {
 3        this.health -= weapon.getDamage(); // 老的基礎規則
 4        if (Weapon instanceof Gun) { // 新的邏輯
 5            this.setHealth(0);
 6        }
 7    }
 8}
 9public class Dragon extends Monster {
10    public void receiveDamageBy(Weapon weapon, Player player) {
11        if (Weapon instanceof Gun) { // 新的邏輯
12                      super.receiveDamageBy(weapon, player);
13        }
14        // 老的邏輯省略
15    }
16}

在一個複雜的軟件中爲什麼會建議 “儘量” 不要違背 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 類中都增加類似的邏輯：

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

1public abstract class Movable {
2    int x;
3    int y;
4    void move(int targetX, int targetY) {
5        // logic
6    }
7}
8public abstract class Player extends Movable;
9public 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 案例的僞代碼如下：

 1public class Entity {
 2  public Vector position; // 此處Vector是一個Component, 指向的是MovementSystem.list裏的一個
 3}
 4public class MovementSystem {
 5  List<Vector> list;
 6  // System的行爲
 7  public void update(float delta) {
 8    for(Vector pos : list) { // 這個loop直接走了CPU緩存，性能很高，同時可以用SIMD優化
 9      pos.x = pos.x + delta;
10      pos.y = pos.y + delta;
11    }
12  }
13}
14@Test
15public void test() {
16  MovementSystem system = new MovementSystem();
17  system.list = new List<>() { new Vector(0, 0) };
18  Entity entity = new Entity(list.get(0));
19  system.update(0.1);
20  assertTrue(entity.position.x == 0.1);
21}

由於本文不是講解 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、耐久等。

 1public class Player implements Movable {
 2    private PlayerId id;
 3    private String name;
 4    private PlayerClass playerClass; // enum
 5    private WeaponId weaponId; // （Note 1）
 6    private Transform position = Transform.ORIGIN;
 7    private Vector velocity = Vector.ZERO;
 8}
 9public class Monster implements Movable {
10    private MonsterId id;
11    private MonsterClass monsterClass; // enum
12    private Health health;
13    private Transform position = Transform.ORIGIN;
14    private Vector velocity = Vector.ZERO;
15}
16public class Weapon {
17    private WeaponId id;
18    private String name;
19    private WeaponType weaponType; // enum
20    private int damage;
21    private int damageType; // 0 - physical, 1 - fire, 2 - ice
22}

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

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

值對象的組件化

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

 1public interface Movable {
 2    // 相當於組件
 3    Transform getPosition();
 4    Vector getVelocity();
 5    // 行爲
 6    void moveTo(long x, long y);
 7    void startMove(long velX, long velY);
 8    void stopMove();
 9    boolean isMoving();
10}
11// 具體實現
12public class Player implements Movable {
13    public void moveTo(long x, long y) {
14        this.position = new Transform(x, y);
15    }
16    public void startMove(long velocityX, long velocityY) {
17        this.velocity = new Vector(velocityX, velocityY);
18    }
19    public void stopMove() {
20        this.velocity = Vector.ZERO;
21    }
22    @Override
23    public boolean isMoving() {
24        return this.velocity.getX() != 0 || this.velocity.getY() != 0;
25    }
26}
27@Value
28public class Transform {
29    public static final Transform ORIGIN = new Transform(0, 0);
30    long x;
31    long y;
32}
33@Value
34public class Vector {
35    public static final Vector ZERO = new Vector(0, 0);
36    long x;
37    long y;
38}

注意兩點：

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

▐ 裝備行爲

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

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

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

1public class Player {
2    @Autowired
3    EquipmentService equipmentService; // BAD: 不可以直接依賴
4    public void equip(Weapon weapon) {
5       // ...
6    }
7}

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

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

1public class Player {
2    public void equip(Weapon weapon, EquipmentService equipmentService) {
3        if (equipmentService.canEquip(this, weapon)) {
4            this.weaponId = weapon.getId();
5        } else {
6            throw new IllegalArgumentException("Cannot Equip: " + weapon);
7        }
8    }
9}

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

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

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

 1public class EquipmentServiceImpl implements EquipmentService {
 2    private EquipmentManager equipmentManager; 
 3    @Override
 4    public boolean canEquip(Player player, Weapon weapon) {
 5        return equipmentManager.canEquip(player, weapon);
 6    }
 7}
 8// 策略優先級管理
 9public class EquipmentManager {
10    private static final List<EquipmentPolicy> POLICIES = new ArrayList<>();
11    static {
12        POLICIES.add(new FighterEquipmentPolicy());
13        POLICIES.add(new MageEquipmentPolicy());
14        POLICIES.add(new DragoonEquipmentPolicy());
15        POLICIES.add(new DefaultEquipmentPolicy());
16    }
17    public boolean canEquip(Player player, Weapon weapon) {
18        for (EquipmentPolicy policy : POLICIES) {
19            if (!policy.canApply(player, weapon)) {
20                continue;
21            }
22            return policy.canEquip(player, weapon);
23        }
24        return false;
25    }
26}
27// 策略案例
28public class FighterEquipmentPolicy implements EquipmentPolicy {
29    @Override
30    public boolean canApply(Player player, Weapon weapon) {
31        return player.getPlayerClass() == PlayerClass.Fighter;
32    }
33    /**
34     * Fighter能裝備Sword和Dagger
35     */
36    @Override
37    public boolean canEquip(Player player, Weapon weapon) {
38        return weapon.getWeaponType() == WeaponType.Sword
39                || weapon.getWeaponType() == WeaponType.Dagger;
40    }
41}
42// 其他策略省略，見源碼

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

▐ 攻擊行爲

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

 1public interface CombatService {
 2    void performAttack(Player player, Monster monster);
 3}
 4public class CombatServiceImpl implements CombatService {
 5    private WeaponRepository weaponRepository;
 6    private DamageManager damageManager;
 7    @Override
 8    public void performAttack(Player player, Monster monster) {
 9        Weapon weapon = weaponRepository.find(player.getWeaponId());
10        int damage = damageManager.calculateDamage(player, weapon, monster);
11        if (damage > 0) {
12            monster.takeDamage(damage); // （Note 1）在領域服務裏變更Monster
13        }
14        // 省略掉Player和Weapon可能受到的影響
15    }
16}

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

 1// 策略優先級管理
 2public class DamageManager {
 3    private static final List<DamagePolicy> POLICIES = new ArrayList<>();
 4    static {
 5        POLICIES.add(new DragoonPolicy());
 6        POLICIES.add(new DragonImmunityPolicy());
 7        POLICIES.add(new OrcResistancePolicy());
 8        POLICIES.add(new ElfResistancePolicy());
 9        POLICIES.add(new PhysicalDamagePolicy());
10        POLICIES.add(new DefaultDamagePolicy());
11    }
12    public int calculateDamage(Player player, Weapon weapon, Monster monster) {
13        for (DamagePolicy policy : POLICIES) {
14            if (!policy.canApply(player, weapon, monster)) {
15                continue;
16            }
17            return policy.calculateDamage(player, weapon, monster);
18        }
19        return 0;
20    }
21}
22// 策略案例
23public class DragoonPolicy implements DamagePolicy {
24    public int calculateDamage(Player player, Weapon weapon, Monster monster) {
25        return weapon.getDamage() * 2;
26    }
27    @Override
28    public boolean canApply(Player player, Weapon weapon, Monster monster) {
29        return player.getPlayerClass() == PlayerClass.Dragoon &&
30                monster.getMonsterClass() == MonsterClass.Dragon;
31    }
32}

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

▐ 單元測試

 1@Test
 2@DisplayName("Dragoon attack dragon doubles damage")
 3public void testDragoonSpecial() {
 4    // Given
 5    Player dragoon = playerFactory.createPlayer(PlayerClass.Dragoon, "Dart");
 6    Weapon sword = weaponFactory.createWeaponFromPrototype(swordProto, "Soul Eater", 60);
 7    ((WeaponRepositoryMock)weaponRepository).cache(sword);
 8    dragoon.equip(sword, equipmentService);
 9    Monster dragon = monsterFactory.createMonster(MonsterClass.Dragon, 100);
10    // When
11    combatService.performAttack(dragoon, dragon);
12    // Then
13    assertThat(dragon.getHealth()).isEqualTo(Health.ZERO);
14    assertThat(dragon.isAlive()).isFalse();
15}
16@Test
17@DisplayName("Orc should receive half damage from physical weapons")
18public void testFighterOrc() {
19    // Given
20    Player fighter = playerFactory.createPlayer(PlayerClass.Fighter, "MyFighter");
21    Weapon sword = weaponFactory.createWeaponFromPrototype(swordProto, "My Sword");
22    ((WeaponRepositoryMock)weaponRepository).cache(sword);
23    fighter.equip(sword, equipmentService);
24    Monster orc = monsterFactory.createMonster(MonsterClass.Orc, 100);
25    // When
26    combatService.performAttack(fighter, orc);
27    // Then
28    assertThat(orc.getHealth()).isEqualTo(Health.of(100 - 10 / 2));
29}

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

▐ 移動系統

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

 1public class MovementSystem {
 2    private static final long X_FENCE_MIN = -100;
 3    private static final long X_FENCE_MAX = 100;
 4    private static final long Y_FENCE_MIN = -100;
 5    private static final long Y_FENCE_MAX = 100;
 6    private List<Movable> entities = new ArrayList<>();
 7    public void register(Movable movable) {
 8        entities.add(movable);
 9    }
10    public void update() {
11        for (Movable entity : entities) {
12            if (!entity.isMoving()) {
13                continue;
14            }
15            Transform old = entity.getPosition();
16            Vector vel = entity.getVelocity();
17            long newX = Math.max(Math.min(old.getX() + vel.getX(), X_FENCE_MAX), X_FENCE_MIN);
18            long newY = Math.max(Math.min(old.getY() + vel.getY(), Y_FENCE_MAX), Y_FENCE_MIN);
19            entity.moveTo(newX, newY);
20        }
21    }
22}

單測：

 1@Test
 2@DisplayName("Moving player and monster at the same time")
 3public void testMovement() {
 4    // Given
 5    Player fighter = playerFactory.createPlayer(PlayerClass.Fighter, "MyFighter");
 6    fighter.moveTo(2, 5);
 7    fighter.startMove(1, 0);
 8    Monster orc = monsterFactory.createMonster(MonsterClass.Orc, 100);
 9    orc.moveTo(10, 5);
10    orc.startMove(-1, 0);
11    movementSystem.register(fighter);
12    movementSystem.register(orc);
13    // When
14    movementSystem.update();
15    // Then
16    assertThat(fighter.getPosition().getX()).isEqualTo(2 + 1);
17    assertThat(orc.getPosition().getX()).isEqualTo(10 - 1);
18}

在這裏 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 裏有合理的默認值。

比如，賬號的創建：

 1public class Account {
 2    private String accountNumber;
 3    private Long amount;
 4}
 5@Test
 6public void test() {
 7    Account account = new Account();
 8    account.setAmount(100L);
 9    TransferService.transfer(account); // 報錯了，因爲Account缺少必要的AccountNumber
10}

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

 1public class Account {
 2    public Account(String accountNumber, Long amount) {
 3        assert StringUtils.isNotBlank(accountNumber);
 4        assert amount >= 0;
 5        this.accountNumber = accountNumber;
 6        this.amount = amount;
 7    }
 8}
 9@Test
10public void test() {
11    Account account = new Account("123", 100L); // 確保對象的有效性
12}

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

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

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

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

儘量避免 public setter

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

 1@Data @Setter(AccessLevel.PRIVATE) // 確保不生成public setter
 2public class Order {
 3    private int status; // 0 - 創建，1 - 支付，2 - 發貨，3 - 收貨
 4    private Payment payment; // 支付單
 5    private Shipping shipping; // 物流單
 6    public void pay(Long userId, Long amount) {
 7        if (status != 0) {
 8            throw new IllegalStateException();
 9        }
10        this.status = 1;
11        this.payment = new Payment(userId, amount);
12    }
13    public void ship(String trackingNumber) {
14        if (status != 1) {
15            throw new IllegalStateException();
16        }
17        this.status = 2;
18        this.shipping = new Shipping(trackingNumber);
19    }
20}

【建議】在有些簡單場景裏，有時候確實可以比較隨意的設置一個值而不會導致不一致性，也建議將方法名重新寫爲比較 “行爲化” 的命名，會增強其語意。比如 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 來反轉調用領域服務的方法，比如：

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

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

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

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

跨對象事務型

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

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

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

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

1public void test() {
2    //...
3    combatService.performAttack(mage, orc);
4}

這個原則也映射了 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 裏：

1public class CombatService {
2    public void performAttack(Player player, Monster monster) {
3        // ...
4        monster.takeDamage(damage);
5        if (!monster.isAlive()) {
6            player.receiveExp(10); // 收到經驗
7        }
8    }
9}

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

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

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

 1public class CombatService {
 2    public void performAttack(Player player, Monster monster) {
 3        // ...
 4        monster.takeDamage(damage);
 5        if (!monster.isAlive()) {
 6            player.receiveExp(10); // 收到經驗
 7            if (player.canLevelUp()) {
 8                player.levelUp(); // 升級
 9            }
10        }
11    }
12}

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

▐ 領域事件介紹

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

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

▐ 領域事件實現

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

 1// 實現者：瑜進 2019/11/28
 2public class EventBus {
 3    // 註冊器
 4    @Getter
 5    private final EventRegistry invokerRegistry = new EventRegistry(this);
 6    // 事件分發器
 7    private final EventDispatcher dispatcher = new EventDispatcher(ExecutorFactory.getDirectExecutor());
 8    // 異步事件分發器
 9    private final EventDispatcher asyncDispatcher = new EventDispatcher(ExecutorFactory.getThreadPoolExecutor());
10    // 事件分發
11    public boolean dispatch(Event event) {
12        return dispatch(event, dispatcher);
13    }
14    // 異步事件分發
15    public boolean dispatchAsync(Event event) {
16        return dispatch(event, asyncDispatcher);
17    }
18    // 內部事件分發
19    private boolean dispatch(Event event, EventDispatcher dispatcher) {
20        checkEvent(event);
21        // 1.獲取事件數組
22        Set<Invoker> invokers = invokerRegistry.getInvokers(event);
23        // 2.一個事件可以被監聽N次，不關心調用結果
24        dispatcher.dispatch(event, invokers);
25        return true;
26    }
27    // 事件總線註冊
28    public void register(Object listener) {
29        if (listener == null) {
30            throw new IllegalArgumentException("listener can not be null!");
31        }
32        invokerRegistry.register(listener);
33    }
34    private void checkEvent(Event event) {
35        if (event == null) {
36            throw new IllegalArgumentException("event");
37        }
38        if (!(event instanceof Event)) {
39            throw new IllegalArgumentException("Event type must by " + Event.class);
40        }
41    }
42}

調用方式：

 1public class LevelUpEvent implements Event {
 2    private Player player;
 3}
 4public class LevelUpHandler {
 5    public void handle(Player player);
 6}
 7public class Player {
 8    public void receiveExp(int value) {
 9        this.exp += value;
10        if (this.exp >= 100) {
11            LevelUpEvent event = new LevelUpEvent(this);
12            EventBus.dispatch(event);
13            this.exp = 0;
14        }
15    }
16}
17@Test
18public void test() {
19    EventBus.register(new LevelUpHandler());
20    player.setLevel(1);
21    player.receiveExp(100);
22    assertThat(player.getLevel()).equals(2);
23}

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

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

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

 1public class Player {
 2  List<Event> events;
 3  public void receiveExp(int value) {
 4        this.exp += value;
 5        if (this.exp >= 100) {
 6            LevelUpEvent event = new LevelUpEvent(this);
 7            events.add(event); // 把event加進去
 8            this.exp = 0;
 9        }
10    }
11}
12@Test
13public void test() {
14    EventBus.register(new LevelUpHandler());
15    player.setLevel(1);
16    player.receiveExp(100);
17    for(Event event: player.getEvents()) { // 在這裏顯性的dispatch事件
18        EventBus.dispatch(event);
19    }
20    assertThat(player.getLevel()).equals(2);
21}

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

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

總結

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

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

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

作者 | 殷浩

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650414919&idx=1&sn=0ad1df1a1b0e2488f7faa21008fdbdd0&chksm=8396d75fb4e15e49341b07022780dcb8dca66a0efb7f129d4de86a5ef5d8a890f6e0d2fd6432&scene=132#wechat_redirect