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

作者 | 殷浩
來源 | 阿里技術(shù)公眾號

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

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

1 背景和規(guī)則

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

基礎(chǔ)配置如下：

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

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

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

2 OOP實現(xiàn)

對于熟悉Object-Oriented Programming的同學(xué)，一個比較簡單的實現(xiàn)是通過類的繼承關(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 {}

而實現(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 {@Overridepublic 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 {@Overridepublic void receiveDamageBy(Weapon weapon, Player player) {if (player instanceof Dragoon) {this.setHealth(this.getHealth() - weapon.getDamage() * 2); // 龍騎傷害規(guī)則}// else no damage, 龍免疫力規(guī)則} }

然后跑幾個單測：

public class BattleTest {@Test@DisplayName("Dragon is immune to attacks")public void testDragonImmunity() {// GivenFighter fighter = new Fighter("Hero");Sword sword = new Sword("Excalibur", 10);fighter.setWeapon(sword);Dragon dragon = new Dragon("Dragon", 100L);// Whenfighter.attack(dragon);// ThenassertThat(dragon.getHealth()).isEqualTo(100);}@Test@DisplayName("Dragoon attack dragon doubles damage")public void testDragoonSpecial() {// GivenDragoon dragoon = new Dragoon("Dragoon");Sword sword = new Sword("Excalibur", 10);dragoon.setWeapon(sword);Dragon dragon = new Dragon("Dragon", 100L);// Whendragoon.attack(dragon);// ThenassertThat(dragon.getHealth()).isEqualTo(100 - 10 * 2);}@Test@DisplayName("Orc should receive half damage from physical weapons")public void testFighterOrc() {// GivenFighter fighter = new Fighter("Hero");Sword sword = new Sword("Excalibur", 10);fighter.setWeapon(sword);Orc orc = new Orc("Orc", 100L);// Whenfighter.attack(orc);// ThenassertThat(orc.getHealth()).isEqualTo(100 - 10 / 2);}@Test@DisplayName("Orc receive full damage from magic attacks")public void testMageOrc() {// GivenMage mage = new Mage("Mage");Staff staff = new Staff("Fire Staff", 10);mage.setWeapon(staff);Orc orc = new Orc("Orc", 100L);// Whenmage.attack(orc);// ThenassertThat(orc.getHealth()).isEqualTo(100 - 10);} }

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

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

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

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

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

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

@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)，但實際上只修改了父類的變量，并沒有修改子類的變量，所以實際不生效，也不拋異常，但結(jié)果是錯的。

當然，可以在父類限制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層面上應(yīng)該開放可用 }

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

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

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

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

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

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

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

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);}// 老的邏輯省略} }

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

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

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

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

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

當我們有不同的對象，但又有相同或類似的行為時，OOP會不可避免的導(dǎo)致代碼的重復(fù)。在這個例子里，如果我們?nèi)ピ黾右粋€“可移動”的行為，需要在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，怎么處理繼承關(guān)系？要知道Java（以及絕大部分語言）是不支持多父類繼承的，所以只能通過重復(fù)代碼來實現(xiàn)。

問題總結(jié)

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

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

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

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

1 ECS介紹

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

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

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

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

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

一個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優(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)分析

重新回來分析ECS，其實它的本源還是幾個很老的概念：

組件化

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

行為抽離

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

數(shù)據(jù)驅(qū)動

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

3 ECS的缺陷

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

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

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

回到我們原來的問題域上面，我們從領(lǐng)域?qū)硬鸱忠幌赂鞣N對象：

實體類

在DDD里，實體類包含ID和內(nèi)部狀態(tài)，在這個案例里實體類包含Player、Monster和Weapon。Weapon被設(shè)計成實體類是因為兩把同名的Weapon應(yīng)該可以同時存在，所以必須要有ID來區(qū)分，同時未來也可以預(yù)期Weapon會包含一些狀態(tài)，比如升級、臨時的buff、耐久等。

public class Player implements Movable {private PlayerId id;private String name;private PlayerClass playerClass; // enumprivate 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; // enumprivate Health health;private Transform position = Transform.ORIGIN;private Vector velocity = Vector.ZERO; }public class Weapon {private WeaponId id;private String name;private WeaponType weaponType; // enumprivate int damage;private int damageType; // 0 - physical, 1 - fire, 2 - ice }

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

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

值對象的組件化

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

public interface Movable {// 相當于組件Transform getPosition();Vector getVelocity();// 行為void moveTo(long x, long y);void startMove(long velX, long velY);void stopMove();boolean isMoving(); }// 具體實現(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;}@Overridepublic 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的規(guī)則是不能直接變更其屬性，必須通過Entity的方法去對內(nèi)部狀態(tài)做變更。這樣能保證數(shù)據(jù)的一致性。
• 抽象Movable的好處是如同ECS一樣，一些特別通用的行為（如在大地圖里移動）可以通過統(tǒng)一的System代碼去處理，避免了重復(fù)勞動。

2 裝備行為

因為我們已經(jīng)不會用Player的子類來決定什么樣的Weapon可以裝備，所以這段邏輯應(yīng)該被拆分到一個單獨的類里。這種類在DDD里被叫做領(lǐng)域服務(wù)（Domain Service）。

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

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

public class Player {@AutowiredEquipmentService 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）設(shè)計模式：

public class EquipmentServiceImpl implements EquipmentService {private EquipmentManager equipmentManager; @Overridepublic 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 {@Overridepublic boolean canApply(Player player, Weapon weapon) {return player.getPlayerClass() == PlayerClass.Fighter;}/*** Fighter能裝備Sword和Dagger*/@Overridepublic boolean canEquip(Player player, Weapon weapon) {return weapon.getWeaponType() == WeaponType.Sword|| weapon.getWeaponType() == WeaponType.Dagger;} }// 其他策略省略，見源碼

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

3 攻擊行為

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

同樣的在這個案例里，可以通過Strategy設(shè)計模式來解決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;}@Overridepublic 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ù)，但實質(zhì)上有很大的差異。上文的EquipmentService更多的是提供只讀策略，且只會影響單個對象，所以可以在Player.equip方法上通過參數(shù)注入。但是CombatService有可能會影響多個對象，所以不能直接通過參數(shù)注入的方式調(diào)用。

4 單元測試

@Test @DisplayName("Dragoon attack dragon doubles damage") public void testDragoonSpecial() {// GivenPlayer 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);// WhencombatService.performAttack(dragoon, dragon);// ThenassertThat(dragon.getHealth()).isEqualTo(Health.ZERO);assertThat(dragon.isAlive()).isFalse(); }@Test @DisplayName("Orc should receive half damage from physical weapons") public void testFighterOrc() {// GivenPlayer 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);// WhencombatService.performAttack(fighter, orc);// ThenassertThat(orc.getHealth()).isEqualTo(Health.of(100 - 10 / 2)); }

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

5 移動系統(tǒng)

最后還有一種Domain Service，通過組件化，我們其實可以實現(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() {// GivenPlayer 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);// WhenmovementSystem.update();// ThenassertThat(fighter.getPosition().getX()).isEqualTo(2 + 1);assertThat(orc.getPosition().getX()).isEqualTo(10 - 1); }

在這里MovementSystem就是一個相對獨立的Domain Service，通過對Movable的組件化，實現(xiàn)了類似代碼的集中化、以及一些通用依賴/配置的中心化（如X、Y邊界等）。

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

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

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

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

1 實體類（Entity）

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

創(chuàng)建即一致

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

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

比如，賬號的創(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); // 報錯了，因為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;} }@Test public void test() {Account account = new Account("123", 100L); // 確保對象的有效性 }

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

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

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等設(shè)計模式就不一一指出了。

盡量避免public setter

一個最容易導(dǎo)致不一致性的原因是實體暴露了public的setter方法，特別是set單一參數(shù)會導(dǎo)致狀態(tài)不一致的情況。比如，一個訂單可能包含訂單狀態(tài)（下單、已支付、已發(fā)貨、已收貨）、支付單、物流單等子實體，如果一個調(diào)用方能隨意去set訂單狀態(tài)，就有可能導(dǎo)致訂單狀態(tài)和子實體匹配不上，導(dǎo)致業(yè)務(wù)流程走不通的情況。所以在實體里，需要通過行為方法來修改內(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);} } 【建議】在有些簡單場景里，有時候確實可以比較隨意的設(shè)置一個值而不會導(dǎo)致不一致性，也建議將方法名重新寫為比較“行為化”的命名，會增強其語意。比如setPosition(x, y)可以叫做moveTo(x, y)，setAddress可以叫做assignAddress等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

單對象策略型

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

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

在這種類型下，實體應(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)用實體對象的方法，從而減少實體對領(lǐng)域服務(wù)的入?yún)⑿鸵蕾嚹?#xff1f;比如，下面這個方法是錯誤的：

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

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

跨對象事務(wù)型

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

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

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

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

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

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

通用組件型

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

3 策略對象（Domain Policy）

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

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

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

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

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

在上文中，有一種類型的領(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的代碼就會變得很復(fù)雜，比如我們再加一個副作用：

當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ù)雜，其根本的原因是反應(yī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/28 public class EventBus {// 注冊器@Getterprivate 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;}} } @Test public 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，而大家都應(yīng)該知道全局Singleton對象很難被單測。這就容易導(dǎo)致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); }

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

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

六 總結(jié)

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

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

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

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

總結(jié)

以上是生活随笔為你收集整理的殷浩详解DDD：领域层设计规范的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。