天天看點

《領域驅動設計:軟體核心複雜性應對之道(修訂版)》—第2章 2.2節“大聲地”模組化

本節書摘來自異步社群《領域驅動設計:軟體核心複雜性應對之道(修訂版)》一書中的第2章,第2.2節“大聲地”模組化,作者【美】埃裡克•埃文斯(eric evans), 馬利偉 , 萬龍,更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

2.2 “大聲地”模組化

假如将交談從溝通方式中除去的話,那會是巨大的損失,因為人類本身頗具談話的天賦。遺憾的是,當人們交談時,通常并不使用領域模型的語言。

可能開始時你并不認為上述論斷是正确的,而且的确有例外情況。但下次你參加需求或設計讨論時,不妨認真聽一下。你将聽到人們用業務術語或者各種業餘術語來描述功能。還會聽到人們讨論技術工件和具體的功能。當然,你還會聽到來自領域模型的術語;在人們共同使用的那部分業務術語中,那些顯而易見的名詞在編碼時通常被用作對象名稱,是以這些術語經常被人們提及。但你是否也聽到一些使用目前領域模型中的關系和互動來描述的措辭呢?

30

改善模型的最佳方式之一就是通過對話來研究,試着大聲說出可能的模型變化中的各種結構。這樣不完善的地方很容易被聽出來。

“如果我們向routing service提供出發地、目的地和到達時間,就可以查詢貨物的停靠地點,嗯……将它們存到資料庫中。”(含糊且偏重于技術)

“出發地、目的地……把它們都輸入到routing service中,而後我們得到一個itinerary,它包含我們所需的全部資訊。”(更具體,但過于啰嗦)

“routing service查找滿足route specification的itinerary。”(簡潔)

使用單詞和短語是極為重要的——其将我們的語言能力用于模組化工作,這就如同素描對于表現視覺和空間推理十分重要一樣。我們即要利用系統性分析和設計方面的分析能力,也要利用對代碼的神秘“感覺”。這些思考方式互為補充,要充分利用它們來找到有用的模型和設計。在所有這些方式中,語言上的試驗常常是最容易被忽視的(本書第三部分将深入探讨這種發現過程,并通過幾段對話來顯示它們之間的互相影響)。

事實上,我們的大腦似乎很擅長處理口語的複雜性(對于像我這樣的門外漢,有本好書是steven pinker所著的the language instinct [pinker 1994])。例如,當具有不同語言背景的人湊在一起做生意時,如果沒有公共語言,他們就會創造一種稱為“混雜語”(pidgin)的公共語言。混雜語雖然不像講話者的母語那樣詳盡,但它适合目前任務。當人們交談時,自然會發現詞語解釋和意義上的差别,而後會自然而然地解決這些差别。他們會發現這種語言中的簡陋晦澀之處并把它們搞順暢。

31

上大學時,我曾經修過西班牙語速成課。課堂上規定不準講英語。起初,令人相當沮喪。這不僅感覺很别扭,而且需要很強的自制力。但最終我和同學們都達到了通過書面練習永遠不可能達到的流利程度。

當我們在讨論中使用領域模型的ubiquitous language時,特别是在開發人員和領域專家一起推敲場景和需求時,通用語言的使用會越來越流利,而且我們還可以互相指點一些細微的差别。我們自然而然地共享了我們所說的語言,而這種方式是圖和文檔無法做到的。

想要在軟體項目上産生一種ubiquitous language,說起來容易,做起來卻難,我們必須充分利用自然賦予我們的才能來實作這個目标。正如人類的視覺和空間思維能力使我們能夠快速傳達和處理圖形概述中的資訊一樣,我們也可以利用自己在基于文法的、有意義的語言方面的天賦來推動模型的開發。

是以,下面這段話可作為ubiquitous language模式的補充:

讨論系統時要結合模型。使用模型元素及其互動來大聲描述場景,并且按照模型允許的方式将各種概念結合到一起。找到更簡單的表達方式來講出你要講的話,然後将這些新的想法應用到圖和代碼中。