導(dǎo)讀

對于一個架構(gòu)師來說，在軟件開發(fā)中如何降低系統(tǒng)復(fù)雜度是一個永恒的挑戰(zhàn)，無論是 94 年 GoF 的 Design Patterns ， 99 年的 Martin Fowler 的 Refactoring ， 02 年的 P of EAA ，還是 03 年的 Enterprise Integration Patterns ，都是通過一系列的設(shè)計模式或范例來降低一些常見的復(fù)雜度。

但是問題在于，這些書的理念是通過技術(shù)手段解決技術(shù)問題，但并沒有從根本上解決業(yè)務(wù)的問題。所以 03 年 Eric Evans 的 Domain Driven Design 一書，以及后續(xù) Vaughn Vernon 的 Implementing DDD ， Uncle Bob 的 Clean Architecture 等書，真正的從業(yè)務(wù)的角度出發(fā)，為全世界絕大部分做純業(yè)務(wù)的開發(fā)提供了一整套的架構(gòu)思路。

（本系列持續(xù)更新，感興趣請關(guān)注我們知乎號，不錯過下一波干貨）

前言

由于 DDD 不是一套框架，而是一種架構(gòu)思想，所以在代碼層面缺乏了足夠的約束，導(dǎo)致 DDD 在實際應(yīng)用中上手門檻很高，甚至可以說絕大部分人都對 DDD 的理解有所偏差。舉個例子， Martin Fowler 在他個人博客里描述的一個 Anti-pattern，Anemic Domain Model ①（貧血域模型）在實際應(yīng)用當中層出不窮，而一些仍然火熱的 ORM 工具比如 Hibernate，Entity Framework 實際上助長了貧血模型的擴散。同樣的，傳統(tǒng)的基于數(shù)據(jù)庫技術(shù)以及 MVC 的四層應(yīng)用架構(gòu)（UI、Business、Data Access、Database），在一定程度上和 DDD 的一些概念混淆，導(dǎo)致絕大部分人在實際應(yīng)用當中僅僅用到了 DDD 的建模的思想，而其對于整個架構(gòu)體系的思想無法落地。

我第一次接觸 DDD 應(yīng)該是 2012 年，當時除了大型互聯(lián)網(wǎng)公司，基本上商業(yè)應(yīng)用都還處于單機的時代，服務(wù)化的架構(gòu)還局限于單機 +LB 用 MVC 提供 Rest 接口供外部調(diào)用，或者用 SOAP 或 WebServices 做 RPC 調(diào)用，但其實更多局限于對外部依賴的協(xié)議。讓我關(guān)注到 DDD 思想的是一個叫 Anti-Corruption Layer（防腐層）的概念，特別是其在解決外部依賴頻繁變更的情況下，如何將核心業(yè)務(wù)邏輯和外部依賴隔離的機制。到了 2014 年， SOA 開始大行其道，微服務(wù)的概念開始冒頭，而如何將一個 Monolith 應(yīng)用合理的拆分為多個微服務(wù)成為了各大論壇的熱門話題，而 DDD 里面的 Bounded Context（限界上下文）的思想為微服務(wù)拆分提供了一套合理的框架。而在今天，在一個所有的東西都能被稱之為“服務(wù)”的時代（XAAS）， DDD 的思想讓我們能冷靜下來，去思考到底哪些東西可以被服務(wù)化拆分，哪些邏輯需要聚合，才能帶來最小的維護成本，而不是簡單的去追求開發(fā)效率。

所以今天，我開始這個關(guān)于 DDD 的一系列文章，希望能繼續(xù)在總結(jié)前人的基礎(chǔ)上發(fā)揚光大 DDD 的思想，但是通過一套我認為合理的代碼結(jié)構(gòu)、框架和約束，來降低 DDD 的實踐門檻，提升代碼質(zhì)量、可測試性、安全性、健壯性。

未來會覆蓋的內(nèi)容包括：

• 最佳架構(gòu)實踐：六邊形應(yīng)用架構(gòu) / Clean 架構(gòu)的核心思想和落地方案
• 持續(xù)發(fā)現(xiàn)和交付：Event Storming > Context Map > Design Heuristics > Modelling
• 降低架構(gòu)腐敗速度：通過 Anti-Corruption Layer 集成第三方庫的模塊化方案
• 標準組件的規(guī)范和邊界：Entity, Aggregate, Repository, Domain Service, Application Service, Event, DTO Assembler 等
• 基于 Use Case 重定義應(yīng)用服務(wù)的邊界
• 基于 DDD 的微服務(wù)化改造及顆粒度控制
• CQRS 架構(gòu)的改造和挑戰(zhàn)
• 基于事件驅(qū)動的架構(gòu)的挑戰(zhàn)
• 等等

今天先給大家?guī)硪黄罨A(chǔ)，但極其有價值的Domain Primitive的概念。

?

Domain Primitive

就好像在學(xué)任何語言時首先需要了解的是基礎(chǔ)數(shù)據(jù)類型一樣，在全面了解 DDD 之前，首先給大家介紹一個最基礎(chǔ)的概念: Domain Primitive（DP）。

Primitive 的定義是：

不從任何其他事物發(fā)展而來
初級的形成或生長的早期階段

就好像 Integer、String 是所有編程語言的Primitive一樣，在 DDD 里， DP 可以說是一切模型、方法、架構(gòu)的基礎(chǔ)，而就像 Integer、String 一樣， DP 又是無所不在的。所以，第一講會對 DP 做一個全面的介紹和分析，但我們先不去講概念，而是從案例入手，看看為什么 DP 是一個強大的概念。

?

案例分析

我們先看一個簡單的例子，這個 case 的業(yè)務(wù)邏輯如下：

一個新應(yīng)用在全國通過 地推業(yè)務(wù)員 做推廣，需要做一個用戶注冊系統(tǒng)，同時希望在用戶注冊后能夠通過用戶電話（先假設(shè)僅限座機）的地域（區(qū)號）對業(yè)務(wù)員發(fā)獎金。

先不要去糾結(jié)這個根據(jù)用戶電話去發(fā)獎金的業(yè)務(wù)邏輯是否合理，也先不要去管用戶是否應(yīng)該在注冊時和業(yè)務(wù)員做綁定，這里我們看的主要還是如何更加合理的去實現(xiàn)這個邏輯。一個簡單的用戶和用戶注冊的代碼實現(xiàn)如下：

public class User {Long userId;String name;String phone;String address;Long repId; }public class RegistrationServiceImpl implements RegistrationService {private SalesRepRepository salesRepRepo;private UserRepository userRepo;public User register(String name, String phone, String address) throws ValidationException {// 校驗邏輯if (name == null || name.length() == 0) {throw new ValidationException("name");}if (phone == null || !isValidPhoneNumber(phone)) {throw new ValidationException("phone");}// 此處省略address的校驗邏輯// 取電話號里的區(qū)號，然后通過區(qū)號找到區(qū)域內(nèi)的SalesRepString areaCode = null;String[] areas = new String[]{"0571", "021", "010"};for (int i = 0; i < phone.length(); i++) {String prefix = phone.substring(0, i);if (Arrays.asList(areas).contains(prefix)) {areaCode = prefix;break;}}SalesRep rep = salesRepRepo.findRep(areaCode);// 最后創(chuàng)建用戶，落盤，然后返回User user = new User();user.name = name;user.phone = phone;user.address = address;if (rep != null) {user.repId = rep.repId;}return userRepo.save(user);}private boolean isValidPhoneNumber(String phone) {String pattern = "^0[1-9]{2,3}-?\\d{8}$";return phone.matches(pattern);} }

我們?nèi)粘＝^大部分代碼和模型其實都跟這個是類似的，乍一看貌似沒啥問題，但我們再深入一步，從以下四個維度去分析一下：接口的清晰度（可閱讀性）、數(shù)據(jù)驗證和錯誤處理、業(yè)務(wù)邏輯代碼的清晰度、和可測試性。

▍問題1 - 接口的清晰度

在Java代碼中，對于一個方法來說所有的參數(shù)名在編譯時丟失，留下的僅僅是一個參數(shù)類型的列表，所以我們重新看一下以上的接口定義，其實在運行時僅僅是：

User register(String, String, String);

所以以下的代碼是一段編譯器完全不會報錯的，很難通過看代碼就能發(fā)現(xiàn)的 bug ：

service.register("殷浩", "浙江省杭州市余杭區(qū)文三西路969號", "0571-12345678");

當然，在真實代碼中運行時會報錯，但這種 bug 是在運行時被發(fā)現(xiàn)的，而不是在編譯時。普通的 Code Review 也很難發(fā)現(xiàn)這種問題，很有可能是代碼上線后才會被暴露出來。這里的思考是，有沒有辦法在編碼時就避免這種可能會出現(xiàn)的問題？

另外一種常見的，特別是在查詢服務(wù)中容易出現(xiàn)的例子如下：

User findByName(String name); User findByPhone(String phone); User findByNameAndPhone(String name, String phone);

在這個場景下，由于入?yún)⒍际?String 類型，不得不在方法名上面加上?ByXXX?來區(qū)分，而?findByNameAndPhone?同樣也會陷入前面的入?yún)㈨樞蝈e誤的問題，而且和前面的入?yún)⒉煌?#xff0c;這里參數(shù)順序如果輸錯了，方法不會報錯只會返回?null，而這種 bug 更加難被發(fā)現(xiàn)。這里的思考是，有沒有辦法讓方法入?yún)⒁荒苛巳?#xff0c;避免入?yún)㈠e誤導(dǎo)致的 bug ？

▍問題2 - 數(shù)據(jù)驗證和錯誤處理

在前面這段數(shù)據(jù)校驗代碼：

if (phone == null || !isValidPhoneNumber(phone)) {throw new ValidationException("phone"); }

在日常編碼中經(jīng)常會出現(xiàn)，一般來說這種代碼需要出現(xiàn)在方法的最前端，確保能夠 fail-fast 。但是假設(shè)你有多個類似的接口和類似的入?yún)?#xff0c;在每個方法里這段邏輯會被重復(fù)。而更嚴重的是如果未來我們要拓展電話號去包含手機時，很可能需要加入以下代碼：

if (phone == null || !isValidPhoneNumber(phone) || !isValidCellNumber(phone)) {throw new ValidationException("phone"); }

如果你有很多個地方用到了 phone 這個入?yún)?#xff0c;但是有個地方忘記修改了，會造成 bug 。這是一個 DRY 原則被違背時經(jīng)常會發(fā)生的問題。

如果有個新的需求，需要把入?yún)㈠e誤的原因返回，那么這段代碼就變得更加復(fù)雜：

if (phone == null) {throw new ValidationException("phone不能為空"); } else if (!isValidPhoneNumber(phone)) {throw new ValidationException("phone格式錯誤"); }

可以想像得到，代碼里充斥著大量的類似代碼塊時，維護成本要有多高。

最后，在這個業(yè)務(wù)方法里，會（隱性或顯性的）拋?ValidationException，所以需要外部調(diào)用方去try/catch，而業(yè)務(wù)邏輯異常和數(shù)據(jù)校驗異常被混在了一起，是否是合理的？

在傳統(tǒng)Java架構(gòu)里有幾個辦法能夠去解決一部分問題，常見的如BeanValidation注解或ValidationUtils類，比如：

// Use Bean Validation User registerWithBeanValidation(@NotNull @NotBlank String name,@NotNull @Pattern(regexp = "^0?[1-9]{2,3}-?\\d{8}$") String phone,@NotNull String address );// Use ValidationUtils: public User registerWithUtils(String name, String phone, String address) {ValidationUtils.validateName(name); // throws ValidationExceptionValidationUtils.validatePhone(phone);ValidationUtils.validateAddress(address);... }

但這幾個傳統(tǒng)的方法同樣有問題，

BeanValidation：

• 通常只能解決簡單的校驗邏輯，復(fù)雜的校驗邏輯一樣要寫代碼實現(xiàn)定制校驗器
• 在添加了新校驗邏輯時，同樣會出現(xiàn)在某些地方忘記添加一個注解的情況，DRY原則還是會被違背

?

ValidationUtils類：

• 當大量的校驗邏輯集中在一個類里之后，違背了Single Responsibility單一性原則，導(dǎo)致代碼混亂和不可維護
• 業(yè)務(wù)異常和校驗異常還是會混雜

所以，有沒有一種方法，能夠一勞永逸的解決所有校驗的問題以及降低后續(xù)的維護成本和異常處理成本呢？

▍問題3 - 業(yè)務(wù)代碼的清晰度

在這段代碼里：

String areaCode = null; String[] areas = new String[]{"0571", "021", "010"}; for (int i = 0; i < phone.length(); i++) {String prefix = phone.substring(0, i);if (Arrays.asList(areas).contains(prefix)) {areaCode = prefix;break;} } SalesRep rep = salesRepRepo.findRep(areaCode);

實際上出現(xiàn)了另外一種常見的情況，那就是從一些入?yún)⒗锍槿∫徊糠謹?shù)據(jù)，然后調(diào)用一個外部依賴獲取更多的數(shù)據(jù)，然后通常從新的數(shù)據(jù)中再抽取部分數(shù)據(jù)用作其他的作用。這種代碼通常被稱作“膠水代碼”，其本質(zhì)是由于外部依賴的服務(wù)的入?yún)⒉⒉环衔覀冊嫉娜雲(yún)?dǎo)致的。比如，如果SalesRepRepository包含一個findRepByPhone的方法，則上面大部分的代碼都不必要了。

所以，一個常見的辦法是將這段代碼抽離出來，變成獨立的一個或多個方法：

private static String findAreaCode(String phone) {for (int i = 0; i < phone.length(); i++) {String prefix = phone.substring(0, i);if (isAreaCode(prefix)) {return prefix;}}return null; }private static boolean isAreaCode(String prefix) {String[] areas = new String[]{"0571", "021"};return Arrays.asList(areas).contains(prefix); }

然后原始代碼變?yōu)?#xff1a;

String areaCode = findAreaCode(phone); SalesRep rep = salesRepRepo.findRep(areaCode);

而為了復(fù)用以上的方法，可能會抽離出一個靜態(tài)工具類?PhoneUtils?。但是這里要思考的是，靜態(tài)工具類是否是最好的實現(xiàn)方式呢？當你的項目里充斥著大量的靜態(tài)工具類，業(yè)務(wù)代碼散在多個文件當中時，你是否還能找到核心的業(yè)務(wù)邏輯呢？

▍問題4 - 可測試性

為了保證代碼質(zhì)量，每個方法里的每個入?yún)⒌拿總€可能出現(xiàn)的條件都要有 TC 覆蓋（假設(shè)我們先不去測試內(nèi)部業(yè)務(wù)邏輯），所以在我們這個方法里需要以下的 TC ：

假如一個方法有 N 個參數(shù)，每個參數(shù)有 M 個校驗邏輯，至少要有 N * M 個 TC 。

如果這時候在該方法中加入一個新的入?yún)⒆侄?fax?，即使?fax?和?phone?的校驗邏輯完全一致，為了保證 TC 覆蓋率，也一樣需要 M 個新的 TC 。

而假設(shè)有 P 個方法中都用到了?phone?這個字段，這 P 個方法都需要對該字段進行測試，也就是說整體需要：

P * N * M

個測試用例才能完全覆蓋所有數(shù)據(jù)驗證的問題，在日常項目中，這個測試的成本非常之高，導(dǎo)致大量的代碼沒被覆蓋到。而沒被測試覆蓋到的代碼才是最有可能出現(xiàn)問題的地方。

在這個情況下，降低測試成本 == 提升代碼質(zhì)量，如何能夠降低測試的成本呢？

?

解決方案

我們回頭先重新看一下原始的 use case，并且標注其中可能重要的概念：

一個新應(yīng)用在全國通過 地推業(yè)務(wù)員 做推廣，需要做一個用戶的注冊系統(tǒng)，在用戶注冊后能夠通過用戶電話號的區(qū)號對業(yè)務(wù)員發(fā)獎金。

在分析了 use case 后，發(fā)現(xiàn)其中地推業(yè)務(wù)員、用戶本身自帶 ID 屬性，屬于 Entity（實體），而注冊系統(tǒng)屬于 Application Service（應(yīng)用服務(wù)），這幾個概念已經(jīng)有存在。但是發(fā)現(xiàn)電話號這個概念卻完全被隱藏到了代碼之中。我們可以問一下自己，取電話號的區(qū)號的邏輯是否屬于用戶（用戶的區(qū)號？）？是否屬于注冊服務(wù)（注冊的區(qū)號？）？如果都不是很貼切，那就說明這個邏輯應(yīng)該屬于一個獨立的概念。所以這里引入我們第一個原則：

Make Implicit Concepts Explicit

將隱性的概念顯性化

在這里，我們可以看到，原來電話號僅僅是用戶的一個參數(shù)，屬于隱形概念，但實際上電話號的區(qū)號才是真正的業(yè)務(wù)邏輯，而我們需要將電話號的概念顯性化，通過寫一個Value Object：

public class PhoneNumber {private final String number;public String getNumber() {return number;}public PhoneNumber(String number) {if (number == null) {throw new ValidationException("number不能為空");} else if (isValid(number)) {throw new ValidationException("number格式錯誤");}this.number = number;}public String getAreaCode() {for (int i = 0; i < number.length(); i++) {String prefix = number.substring(0, i);if (isAreaCode(prefix)) {return prefix;}}return null;}private static boolean isAreaCode(String prefix) {String[] areas = new String[]{"0571", "021", "010"};return Arrays.asList(areas).contains(prefix);}public static boolean isValid(String number) {String pattern = "^0?[1-9]{2,3}-?\\d{8}$";return number.matches(pattern);}}

這里面有幾個很重要的元素：

通過?private final String number?確保?PhoneNumber?是一個（Immutable）Value Object。（一般來說 VO 都是 Immutable 的，這里只是重點強調(diào)一下）

校驗邏輯都放在了 constructor 里面，確保只要?PhoneNumber?類被創(chuàng)建出來后，一定是校驗通過的。

之前的?findAreaCode?方法變成了?PhoneNumber?類里的?getAreaCode?，突出了?areaCode?是?PhoneNumber?的一個計算屬性。

這樣做完之后，我們發(fā)現(xiàn)把?PhoneNumber?顯性化之后，其實是生成了一個 Type（數(shù)據(jù)類型）和一個 Class（類）：

• Type 指我們在今后的代碼里可以通過?PhoneNumber?去顯性的標識電話號這個概念
• Class 指我們可以把所有跟電話號相關(guān)的邏輯完整的收集到一個文件里

這兩個概念加起來，構(gòu)造成了本文標題的 Domain Primitive（DP）。

我們看一下全面使用了 DP 之后效果：

public class User {UserId userId;Name name;PhoneNumber phone;Address address;RepId repId; }public User register(@NotNull Name name,@NotNull PhoneNumber phone,@NotNull Address address ) {// 找到區(qū)域內(nèi)的SalesRepSalesRep rep = salesRepRepo.findRep(phone.getAreaCode());// 最后創(chuàng)建用戶，落盤，然后返回，這部分代碼實際上也能用Builder解決User user = new User();user.name = name;user.phone = phone;user.address = address;if (rep != null) {user.repId = rep.repId;}return userRepo.saveUser(user); }

我們可以看到在使用了 DP 之后，所有的數(shù)據(jù)驗證邏輯和非業(yè)務(wù)流程的邏輯都消失了，剩下都是核心業(yè)務(wù)邏輯，可以一目了然。我們重新用上面的四個維度評估一下：

▍評估1 - 接口的清晰度

重構(gòu)后的方法簽名變成了很清晰的：

public User register(Name, PhoneNumber, Address)

而之前容易出現(xiàn)的bug，如果按照現(xiàn)在的寫法

service.register(new Name("殷浩"), new Address("浙江省杭州市余杭區(qū)文三西路969號"), new PhoneNumber("0571-12345678"));

讓接口 API 變得很干凈，易拓展。

▍評估2 - 數(shù)據(jù)驗證和錯誤處理

public User register(@NotNull Name name,@NotNull PhoneNumber phone,@NotNull Address address ) // no throws

如前文代碼展示的，重構(gòu)后的方法里，完全沒有了任何數(shù)據(jù)驗證的邏輯，也不會拋?ValidationException?。原因是因為 DP 的特性，只要是能夠帶到入?yún)⒗锏囊欢ㄊ钦_的或 null（Bean Validation 或 lombok 的注解能解決 null 的問題）。所以我們把數(shù)據(jù)驗證的工作量前置到了調(diào)用方，而調(diào)用方本來就是應(yīng)該提供合法數(shù)據(jù)的，所以更加合適。

再展開來看，使用DP的另一個好處就是代碼遵循了 DRY 原則和單一性原則，如果未來需要修改?PhoneNumber?的校驗邏輯，只需要在一個文件里修改即可，所有使用到了?PhoneNumber?的地方都會生效。

▍評估3 - 業(yè)務(wù)代碼的清晰度

SalesRep rep = salesRepRepo.findRep(phone.getAreaCode()); User user = xxx; return userRepo.save(user);

除了在業(yè)務(wù)方法里不需要校驗數(shù)據(jù)之外，原來的一段膠水代碼?findAreaCode?被改為了?PhoneNumber?類的一個計算屬性?getAreaCode?，讓代碼清晰度大大提升。而且膠水代碼通常都不可復(fù)用，但是使用了 DP 后，變成了可復(fù)用、可測試的代碼。我們能看到，在刨除了數(shù)據(jù)驗證代碼、膠水代碼之后，剩下的都是核心業(yè)務(wù)邏輯。（ Entity 相關(guān)的重構(gòu)在后面文章會談到，這次先忽略）

▍評估4 - 可測試性

當我們將?PhoneNumber?抽取出來之后，在來看測試的 TC ：

• 首先?PhoneNumber?本身還是需要 M 個測試用例，但是由于我們只需要測試單一對象，每個用例的代碼量會大大降低，維護成本降低。
• 每個方法里的每個參數(shù)，現(xiàn)在只需要覆蓋為 null 的情況就可以了，其他的 case 不可能發(fā)生（因為只要不是 null 就一定是合法的）

所以，單個方法的 TC 從原來的 N * M 變成了今天的 N + M 。同樣的，多個方法的 TC 數(shù)量變成了

N + M + P

這個數(shù)量一般來說要遠低于原來的數(shù)量 N* M * P ，讓測試成本極大的降低。

▍評估總結(jié)

進階使用

在上文我介紹了 DP 的第一個原則：將隱性的概念顯性化。在這里我將介紹 DP 的另外兩個原則，用一個新的案例。

▍案例1 - 轉(zhuǎn)賬

假設(shè)現(xiàn)在要實現(xiàn)一個功能，讓A用戶可以支付 x 元給用戶 B ，可能的實現(xiàn)如下：

public void pay(BigDecimal money, Long recipientId) {BankService.transfer(money, "CNY", recipientId); }

如果這個是境內(nèi)轉(zhuǎn)賬，并且境內(nèi)的貨幣永遠不變，該方法貌似沒啥問題，但如果有一天貨幣變更了（比如歐元區(qū)曾經(jīng)出現(xiàn)的問題），或者我們需要做跨境轉(zhuǎn)賬，該方法是明顯的 bug ，因為?money?對應(yīng)的貨幣不一定是 CNY 。

在這個 case 里，當我們說“支付 x 元”時，除了 x 本身的數(shù)字之外，實際上是有一個隱含的概念那就是貨幣“元”。但是在原始的入?yún)⒗?#xff0c;之所以只用了?BigDecimal?的原因是我們認為 CNY 貨幣是默認的，是一個隱含的條件，但是在我們寫代碼時，需要把所有隱性的條件顯性化，而這些條件整體組成當前的上下文。所以 DP 的第二個原則是：

Make Implicit Context Explicit

將 隱性的 上下文 顯性化

所以當我們做這個支付功能時，實際上需要的一個入?yún)⑹侵Ц督痤~ + 支付貨幣。我們可以把這兩個概念組合成為一個獨立的完整概念：Money。

@Value public class Money {private BigDecimal amount;private Currency currency;public Money(BigDecimal amount, Currency currency) {this.amount = amount;this.currency = currency;} }

而原有的代碼則變?yōu)?#xff1a;

public void pay(Money money, Long recipientId) {BankService.transfer(money, recipientId); }

通過將默認貨幣這個隱性的上下文概念顯性化，并且和金額合并為?Money?，我們可以避免很多當前看不出來，但未來可能會暴雷的bug。

▍案例2 - 跨境轉(zhuǎn)賬

前面的案例升級一下，假設(shè)用戶可能要做跨境轉(zhuǎn)賬從 CNY 到 USD ，并且貨幣匯率隨時在波動：

public void pay(Money money, Currency targetCurrency, Long recipientId) {if (money.getCurrency().equals(targetCurrency)) {BankService.transfer(money, recipientId);} else {BigDecimal rate = ExchangeService.getRate(money.getCurrency(), targetCurrency);BigDecimal targetAmount = money.getAmount().multiply(new BigDecimal(rate));Money targetMoney = new Money(targetAmount, targetCurrency);BankService.transfer(targetMoney, recipientId);} }

在這個case里，由于?targetCurrency?不一定和?money?的?Curreny?一致，需要調(diào)用一個服務(wù)去取匯率，然后做計算。最后用計算后的結(jié)果做轉(zhuǎn)賬。

這個case最大的問題在于，金額的計算被包含在了支付的服務(wù)中，涉及到的對象也有2個?Currency?，2 個?Money?，1 個?BigDecimal?，總共 5 個對象。這種涉及到多個對象的業(yè)務(wù)邏輯，需要用 DP 包裝掉，所以這里引出 DP 的第三個原則：

Encapsulate Multi-Object Behavior

封裝 多對象 行為

在這個 case 里，可以將轉(zhuǎn)換匯率的功能，封裝到一個叫做?ExchangeRate?的 DP 里：

@Value public class ExchangeRate {private BigDecimal rate;private Currency from;private Currency to;public ExchangeRate(BigDecimal rate, Currency from, Currency to) {this.rate = rate;this.from = from;this.to = to;}public Money exchange(Money fromMoney) {notNull(fromMoney);isTrue(this.from.equals(fromMoney.getCurrency()));BigDecimal targetAmount = fromMoney.getAmount().multiply(rate);return new Money(targetAmount, to);} }

ExchangeRate匯率對象，通過封裝金額計算邏輯以及各種校驗邏輯，讓原始代碼變得極其簡單：

public void pay(Money money, Currency targetCurrency, Long recipientId) {ExchangeRate rate = ExchangeService.getRate(money.getCurrency(), targetCurrency);Money targetMoney = rate.exchange(money);BankService.transfer(targetMoney, recipientId); }

?

討論和總結(jié)

?

▍Domain Primitive 的定義

讓我們重新來定義一下 Domain Primitive ：Domain Primitive 是一個在特定領(lǐng)域里，擁有精準定義的、可自我驗證的、擁有行為的 Value Object 。

• DP是一個傳統(tǒng)意義上的Value Object，擁有Immutable的特性
• DP是一個完整的概念整體，擁有精準定義
• DP使用業(yè)務(wù)域中的原生語言
• DP可以是業(yè)務(wù)域的最小組成部分、也可以構(gòu)建復(fù)雜組合

注：Domain Primitive的概念和命名來自于Dan Bergh Johnsson & Daniel Deogun的書 Secure by Design。

▍使用 Domain Primitive 的三原則

• 讓隱性的概念顯性化
• 讓隱性的上下文顯性化
• 封裝多對象行為

▍Domain Primitive 和 DDD 里 Value Object 的區(qū)別

在 DDD 中， Value Object 這個概念其實已經(jīng)存在：

• 在 Evans 的 DDD 藍皮書中，Value Object 更多的是一個非 Entity 的值對象
• 在Vernon的IDDD紅皮書中，作者更多的關(guān)注了Value Object的Immutability、Equals方法、Factory方法等

Domain Primitive 是 Value Object 的進階版，在原始 VO 的基礎(chǔ)上要求每個 DP 擁有概念的整體，而不僅僅是值對象。在 VO 的 Immutable 基礎(chǔ)上增加了 Validity 和行為。當然同樣的要求無副作用（side-effect free）。

▍Domain Primitive 和 Data Transfer Object (DTO) 的區(qū)別

在日常開發(fā)中經(jīng)常會碰到的另一個數(shù)據(jù)結(jié)構(gòu)是 DTO ，比如方法的入?yún)⒑统鰠ⅰP 和 DTO 的區(qū)別如下：

▍什么情況下應(yīng)該用 Domain Primitive

常見的 DP 的使用場景包括：

• 有格式限制的?String：比如Name，PhoneNumber，OrderNumber，ZipCode，Address等
• 有限制的Integer：比如OrderId（>0），Percentage（0-100%），Quantity（>=0）等
• 可枚舉的?int?：比如?Status（一般不用Enum因為反序列化問題）
• Double?或?BigDecimal：一般用到的?Double?或?BigDecimal?都是有業(yè)務(wù)含義的，比如?Temperature、Money、Amount、ExchangeRate、Rating?等
• 復(fù)雜的數(shù)據(jù)結(jié)構(gòu)：比如?Map<String, List<Integer>>?等，盡量能把?Map?的所有操作包裝掉，僅暴露必要行為

?

實戰(zhàn) - 老應(yīng)用重構(gòu)的流程

在新應(yīng)用中使用 DP 是比較簡單的，但在老應(yīng)用中使用 DP 是可以遵循以下流程按部就班的升級。在此用本文的第一個 case 為例。

▍第一步 - 創(chuàng)建 Domain Primitive，收集所有 DP 行為

在前文中，我們發(fā)現(xiàn)取電話號的區(qū)號這個是一個可以獨立出來的、可以放入 PhoneNumber 這個 Class 的邏輯。類似的，在真實的項目中，以前散落在各個服務(wù)或工具類里面的代碼，可以都抽出來放在 DP 里，成為 DP 自己的行為或?qū)傩浴＿@里面的原則是：所有抽離出來的方法要做到無狀態(tài)，比如原來是 static 的方法。如果原來的方法有狀態(tài)變更，需要將改變狀態(tài)的部分和不改狀態(tài)的部分分離，然后將無狀態(tài)的部分融入 DP 。因為 DP 本身不能帶狀態(tài)，所以一切需要改變狀態(tài)的代碼都不屬于 DP 的范疇。

(代碼參考 PhoneNumber 的代碼，這里不再重復(fù))

▍第二步 - 替換數(shù)據(jù)校驗和無狀態(tài)邏輯

為了保障現(xiàn)有方法的兼容性，在第二步不會去修改接口的簽名，而是通過代碼替換原有的校驗邏輯和根 DP 相關(guān)的業(yè)務(wù)邏輯。比如：

public User register(String name, String phone, String address)throws ValidationException {if (name == null || name.length() == 0) {throw new ValidationException("name");}if (phone == null || !isValidPhoneNumber(phone)) {throw new ValidationException("phone");}String areaCode = null;String[] areas = new String[]{"0571", "021", "010"};for (int i = 0; i < phone.length(); i++) {String prefix = phone.substring(0, i);if (Arrays.asList(areas).contains(prefix)) {areaCode = prefix;break;}}SalesRep rep = salesRepRepo.findRep(areaCode);// 其他代碼... }

通過 DP 替換代碼后：

public User register(String name, String phone, String address)throws ValidationException {Name _name = new Name(name);PhoneNumber _phone = new PhoneNumber(phone);Address _address = new Address(address);SalesRep rep = salesRepRepo.findRep(_phone.getAreaCode());// 其他代碼... }

通過 new PhoneNumber(phone) 這種代碼，替代了原有的校驗代碼。

通過 _phone.getAreaCode() 替換了原有的無狀態(tài)的業(yè)務(wù)邏輯。

▍第三步 - 創(chuàng)建新接口

創(chuàng)建新接口，將DP的代碼提升到接口參數(shù)層：

public User register(Name name, PhoneNumber phone, Address address) {SalesRep rep = salesRepRepo.findRep(phone.getAreaCode()); }

▍第四步 - 修改外部調(diào)用

外部調(diào)用方需要修改調(diào)用鏈路，比如：

service.register("殷浩", "0571-12345678", "浙江省杭州市余杭區(qū)文三西路969號");

改為：

service.register(new Name("殷浩"), new PhoneNumber("0571-12345678"), new Address("浙江省杭州市余杭區(qū)文三西路969號"));

通過以上 4 步，就能讓你的代碼變得更加簡潔、優(yōu)雅、健壯、安全。你還在等什么？今天就去嘗試吧！

鏈接：

①?https://martinfowler.com/bliki/AnemicDomainModel.html

?

關(guān)注我們，后續(xù)還有DDD系列分享。

?

——————————————————————————————————————

阿里巴巴集團淘系技術(shù)部官方賬號。淘系技術(shù)部是阿里巴巴新零售技術(shù)的王牌軍，支撐淘寶、天貓核心電商以及淘寶直播、閑魚、躺平、阿里汽車、阿里房產(chǎn)等創(chuàng)新業(yè)務(wù)，服務(wù)9億用戶，賦能各行業(yè)1000萬商家。我們打造了全球領(lǐng)先的線上新零售技術(shù)平臺，并作為核心技術(shù)團隊保障了11次雙十一購物狂歡節(jié)的成功。

點擊下方主頁關(guān)注我們，你將收獲更多來自阿里一線工程師的技術(shù)實戰(zhàn)技巧&成長經(jīng)歷心得。另，不定期更新最新崗位招聘信息和簡歷內(nèi)推通道，歡迎各位以最短路徑加入我們。

阿里巴巴淘系技術(shù)?www.zhihu.com

?

?

發(fā)布于 2020-12-31

總結(jié)

以上是生活随笔為你收集整理的【转】阿里技术专家详解 DDD 系列 第一讲- Domain Primitive的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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