讀《領域驅動設計-軟體核心複雜性應對之道》有“感”---一個讀者的“抱怨”

上週入手了一本人民郵電出版社的《領域驅動設計-軟體核心複雜性應對之道》，最近抽業餘時間一直在讀，現在看到200頁不到，但是讓人覺得有點鬱悶。也許是我吹毛求疵，沒事兒找事兒，吃飽撐了，覺得翻譯不是那麼的完美。剛剛又在看，可是實在覺得有些惱火。不得不寫下來。為此我找到了領域驅動設計這本書的英文版、清華大學出版社出的那版，用作參照。

下面就是我覺得欠妥的地方，當然不排除是我胡鬧，但也請大家輕拍磚。也請看過此書的童鞋一起交流。

問題1

第2部分的第七章的標題英文為：Isolating the Domain: Introducing the Applications

原書：隔離領域：應用程式的引入(166頁)

me：通過引入應用層隔離領域層，或隔離領域層：引入應用層

這裡我將Applications翻譯成應用層，我是這樣理解的：按照DDD的四層結構，Application的職責就是協調領域層(domain layer)一起處理業務，所以理解為應用層，使用應用層遮蔽領域層，使上層只能依賴下層。

問題2

另外在閱讀第2部分的時候，總是能讀到“客戶”這樣的字眼兒，客戶一般理解為人或者客戶端吧，無意中在書後的附錄中發現有這樣的解釋：客戶：一個程式元素，他呼叫正在設計的元素，使用其功能。個人覺得這個做法不合適吧，按照人的習慣不會先去讀附錄，看完你的“名詞解釋”再去讀正文吧。而且就算你這個解釋很通用，但是真的會給讀者造成誤導(至少剛開始我是被誤導了)，繼續往下讀，才恍然大悟。舉個例子吧，如果是基礎設施層，那個他的客戶就是領域層。為何不能直接在原文中說清楚呢！一定要讀者費勁去猜測嗎。

問題3

These application classes are coordinators. They should not work out the answers to the questions they ask. That is the domain layer's job.

原書：這些應用層類是協調者，他們只是負責提問，而不負責回答，回答是領域層的工作。

me：這些應用層類作為協調者，他們只負責排程，真正的處理工作由領域層完成。

這個可能是我的問題，原文翻譯的也沒什麼大問題，但是從應用層的定義來看，這樣翻譯好像更貼切些。

問題4

None of the associations in the original diagram specified a traversal direction, but bidirectional associations are problematic in a design. Also, traversal direction often captures insight into the domain, deepening the model itself.

原文：圖7-1中的所有關聯都沒有指定遍歷方向，但雙向關聯在設計中是容易產生問題的。此外，只有深入理解領域後才能確定遍歷方向，因此理解遍歷方向能夠是模型更深入。

me：圖7-1中沒有標明關聯的方向，在設計中的雙向關聯通常會引發很多問題。當然關聯方向取決於領域，並且加強模型本身限定。

雖然，知道我這裡提供的翻譯也很不靠譜，但是我能理解到這個程度了。這裡我所糾結的是“traversal ”的翻譯，我用靈格斯翻譯它，的確在計算機裡的意思是遍歷的意思。但遍歷一詞多用於集合吧，這裡如果理解有誤可以批判。哈哈。個人覺得將“traversal direction”翻譯成關聯方向時候是更合適些。後面一句，全是我理解的意思，很可能違背原文。可批判。

問題5

If our application were tracking the inventory of ships, traversal from Carrier Movement to Handling Event would be important. But our business needs to track only the Cargo. Making the association traversable only from Handling Event to Carrier Movement captures that understanding of our business. This also reduces the implementation to a simple object reference, because the direction with multiplicity was disallowed.

原文：這也把實現簡化為一個簡單的物件引用，因為雙向關係已經被禁用。

結合上下文翻譯為： 這個關聯也被簡化為對一個簡單物件的引用，因為這裡在業務上就不需要雙向關聯。

這裡我糾結的是“disallowed”這個詞的翻譯，從上下文看，應該是領域中不需要雙向關聯，所以去掉的。翻譯成“禁用”欠妥。

問題6

There is one circular reference in our model: Cargo knows its Delivery History, which holds a series of Handling Events, which in turn point back to the Cargo. Circular references logically exist in many domains and are sometimes necessary in design as well, but they are tricky to maintain. Implementation choices can help by avoiding holding the same information in two places that must be kept synchronized. In this case, we can make a simple but fragile implementation (in Java) in an initial prototype, by giving Delivery History a List object containing Handling Events. But at some point we'll probably want to drop the collection in favor of a database lookup with Cargoas the key. This discussion will be taken up again when choosing REPOSITORIES. If the query to see the history is relatively infrequent, this should give good performance, simplify maintenance, and reduce the overhead of adding Handling Events. If this query is very frequent, then it is better to go ahead and maintain the direct pointer. These design trade-offs balance simplicity of implementation against performance. The model is the same; it contains the cycle and the bidirectional association.

原文：但在某些時候，我們可能不想使用集合，以便能夠用Cargo作為鍵來執行資料庫查詢。

第一版翻譯：但是有時候我們可能不想使用集合，而選擇把Cargo作為鍵來執行資料庫查詢。

這裡我也翻譯不好，提供出整個段落了，個人覺得第一版的翻譯或許更能讓我接受。

問題7

圖7-5附近總是能發現“指標”這樣的詞彙，但是一讀就會發現，應該是引用或者關聯吧。而且現在很多物件導向的程式語言都將指標這種東西隱藏到內部了，外部根本沒有這樣的概念，有誤導讀者之嫌。原文中的確有“back-pointer ”，但是翻譯成反向引用或反向關聯合適吧。

這就是我目前全部的牢騷，沒有冒犯任何書以及譯者的一丁點兒意思，試著翻譯過幾篇文章，知道翻譯的不容易，但是多多少少感覺譯者或許並不是DDD方面的專家。還有，需要強調下，這裡全部都是個人的感覺，如果哪裡不合適了，也請各位見諒。

輕拍磚。在此謝過了。