2 裝備行為

因?yàn)槲覀円呀?jīng)不會(huì)用Player的子類來決定什么樣的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ù)，也就是說以下的代碼是錯(cuò)誤的：

public class Player { @Autowired EquipmentService equipmentService; // BAD: 不可以直接依賴 public void equip(Weapon weapon) { // ... }}

這里的問題是Entity只能保留自己的狀態(tài)（或非聚合根的對象）。任何其他的對象，無論是否通過依賴注入的方式弄進(jìn)來，都會(huì)破壞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ù)傳入，確保不會(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)先級管理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ì)的最大好處是未來的規(guī)則增加只需要添加新的Policy類，而不需要去改變原有的類。

3 攻擊行為

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

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

// 策略優(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)域服務(wù)和3.2的EquipmentService領(lǐng)域服務(wù)，雖然都是領(lǐng)域服務(wù)，但實(shí)質(zhì)上有很大的差異。上文的EquipmentService更多的是提供只讀策略，且只會(huì)影響單個(gè)對象，所以可以在Player.equip方法上通過參數(shù)注入。但是CombatService有可能會(huì)影響多個(gè)對象，所以不能直接通過參數(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 移動(dòng)系統(tǒng)

最后還有一種Domain Service，通過組件化，我們其實(shí)可以實(shí)現(xiàn)ECS一樣的System，來降低一些重復(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); } }}

單測：

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

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

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

1 實(shí)體類（Entity）

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

創(chuàng)建即一致

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

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

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

public class Account { private String accountNumber; private Long amount;}@Testpublic 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，就無法保障創(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; }}@Testpublic void test() { Account account = new Account("123", 100L); // 確保對象的有效性}

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

另一種方法是通過Factory模式來創(chuàng)建對象，降低一些重復(fù)性的入?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; }}

通過傳入一個(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í)體里，需要通過行為方法來修改內(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); }}

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

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

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

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

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

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

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

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

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

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

另一個(gè)遵守的原因是可以降低未知的變更的風(fēng)險(xiǎn)。在一個(gè)系統(tǒng)里一個(gè)實(shí)體對象的所有變更操作應(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ǐng)域?qū)ο笾饕嫦虻氖菃蝹€(gè)實(shí)體對象的變更，但涉及到多個(gè)領(lǐng)域?qū)ο蠡蛲獠恳蕾嚨囊恍┮?guī)則。在上文中，EquipmentService即為此類：

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

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

為什么這種情況下不能先調(diào)用領(lǐng)域服務(wù)，再調(diào)用實(shí)體對象的方法，從而減少實(shí)體對領(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)生不一致的情況。

跨對象事務(wù)型

當(dāng)一個(gè)行為會(huì)直接修改多個(gè)實(shí)體時(shí)，不能再通過單一實(shí)體的方法作處理，而必須直接使用領(lǐng)域服務(wù)的方法來做操作。在這里，領(lǐng)域服務(wù)更多的起到了跨對象事務(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 策略對象（Domain Policy）

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

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

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

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

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

當(dāng)Monster的生命值降為0后，給Player獎(jiǎng)勵(lì)經(jīng)驗(yà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) } }}

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

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

這時(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(); // 升級 } } }}

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

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

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

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

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

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

// 實(shí)現(xiàn)者：瑜進(jì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.一個(gè)事件可以被監(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)域事件的很好的實(shí)施依賴EventBus、Dispatcher、Invoker這些屬于框架級別的支持。同時(shí)另一個(gè)問題是因?yàn)镋ntity不能直接依賴外部對象，所以EventBus目前只能是一個(gè)全局的Singleton，而大家都應(yīng)該知道全局Singleton對象很難被單測。這就容易導(dǎo)致Entity對象無法被很容易的被完整單測覆蓋全。

另一種解法是侵入Entity，對每個(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; } }}@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);}

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

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

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

當(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)載。

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