簡介： 在一個DDD架構設計中，領域層的設計合理性會直接影響整個架構的代碼結構以及應用層、基礎設施層的設計。可是領域層設計又是有挑戰的任務，特別是在一個業務邏輯相對複雜應用中，每個業務規則是應該放在Entity、ValueObject 仍是 DomainService是值得用心思考的，既要避免將來的擴展性差，又要確保不會過分設計致使複雜性。今天我用一個相對輕鬆易懂的領域作一個案例演示，但在實際業務應用中，不管是交易、營銷仍是互動，均可以用相似的邏輯來實現。前端
做者 | 殷浩
來源 | 阿里技術公衆號程序員
在一個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規範可能會比較累，因此最主要的是梳理一個對象行爲的影響面，而後做出設計決策，即：
- 是僅影響單一對象仍是多個對象
- 規則將來的拓展性、靈活性
- 性能要求
- 反作用的處理，等等
固然，不少時候一個好的設計是多種因素的取捨，須要你們有必定的積累，真正理解每一個架構背後的邏輯和優缺點。一個好的架構師不是有一個正確答案，而是能從多個方案中選出一個最平衡的方案。
本文爲阿里雲原創內容，未經容許不得轉載。