2 裝備行為

因為我們已經(jīng)不會用Player的子類來決定什么樣的Weapon可以裝備，所以這段邏輯應該被拆分到一個單獨的類里。這種類在DDD里被叫做領(lǐng)域服務（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只能保留自己的狀態(tài)（或非聚合根的對象）。任何其他的對象，無論是否通過依賴注入的方式弄進來，都會破壞Entity的Invariance，并且還難以單測。

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

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

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

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

public class EquipmentServiceImpl implements EquipmentService { private EquipmentManager equipmentManager; @Override public boolean canEquip(Player player, Weapon weapon) { return equipmentManager.canEquip(player, weapon); }}// 策略優(yōu)先級管理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; }}// 其他策略省略，見源碼

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

3 攻擊行為

在上文中曾經(jīng)有提起過，到底應該是Player.attack(Monster)還是Monster.receiveDamage(Weapon, Player)？在DDD里，因為這個行為可能會影響到Player、Monster和Weapon，所以屬于跨實體的業(yè)務邏輯。在這種情況下需要通過一個第三方的領(lǐng)域服務（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）在領(lǐng)域服務里變更Monster } // 省略掉Player和Weapon可能受到的影響 }}

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

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

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 移動系統(tǒng)

最后還有一種Domain Service，通過組件化，我們其實可以實現(xiàn)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的組件化，實現(xiàn)了類似代碼的集中化、以及一些通用依賴/配置的中心化（如X、Y邊界等）。

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

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

1 實體類（Entity）

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

創(chuàng)建即一致

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

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

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

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

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

public Account(String accountNumber, Long amount) { assert StringUtils.isNotBlank(accountNumber); assert amount >= 0; this.accountNumber = accountNumber; this.amount = amount; }}@Testpublic void test() { Account account = new Account("123", 100L); // 確保對象的有效性}

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

另一種方法是通過Factory模式來創(chuàng)建對象，降低一些重復性的入?yún)?。比如?/p>

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

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

盡量避免public setter

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

@Data @Setter(AccessLevel.PRIVATE) // 確保不生成public setterpublic 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); }}

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

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

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

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

不可以強依賴其他聚合根實體或領(lǐng)域服務

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

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

如果方法對外部依賴有副作用，不能通過方法入?yún)⒌姆绞剑荒芡ㄟ^Domain Service解決，見下文。

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

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

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

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

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

單對象策略型

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

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

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

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

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

其錯誤的主要原因是缺少了領(lǐng)域服務入?yún)е路椒ㄓ锌赡墚a(chǎn)生不一致的情況。

跨對象事務型

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

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

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

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

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

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

通用組件型

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

3 策略對象（Domain Policy）

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

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

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

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

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

當Monster的生命值降為0后，給Player獎勵經(jīng)驗值

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

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

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

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

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

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

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

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

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

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

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

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

// 實現(xiàn)者：瑜進 2019/11/28public class EventBus { // 注冊器 @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.一個事件可以被監(jiān)聽N次，不關(guān)心調(diào)用結(jié)果 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); } }}

調(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; } }}@Testpublic void test() { EventBus.register(new LevelUpHandler()); player.setLevel(1); player.receiveExp(100); assertThat(player.getLevel()).equals(2);}

3 目前領(lǐng)域事件的缺陷和展望

從上面代碼可以看出來，領(lǐng)域事件的很好的實施依賴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; } }}@Testpublic 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);}

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

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

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

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

作者 | 殷浩

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

以上就是關(guān)于pos機免費設計素材,殷浩詳解DDD的知識，后面我們會繼續(xù)為大家整理關(guān)于pos機免費設計素材的知識，希望能夠幫助到大家！