您好,登錄后才能下訂單哦!
本書是Eric Evans對他自己寫的《領域驅動設計-軟件核心復雜性應對之道》的一本字典式的參考書,可用于快速查找《領域驅動設計》中的諸多概念及其簡明解釋。
上周末電腦硬盤文件莫名丟失,狼狽了大半周才緩過來 T_T 。《Domain Driven Design Reference》的原版pdf也丟了,好在這篇文章提前翻好了,只是這次沒法再次做校對了,大致讀了一遍還算通順,大家講究看吧~
其它本系列其它文章地址:
[譯文]Domain Driven Design Reference(一)—— 前言
[譯文]Domain Driven Design Reference(二)—— 讓模型起作用
[譯文]Domain Driven Design Reference(三)—— 模型驅動設計的構建模塊
[譯文]Domain Driven Design Reference(四)—— 柔性設計
[譯文]Domain Driven Design Reference(五)—— 為戰略設計的上下文映射
[譯文]Domain Driven Design Reference(六)—— 提煉戰略設計
[譯文]Domain Driven Design Reference(七)—— 大型戰略設計結構
在一個大的系統中,沒有任何能夠讓元素按照其在整個設計模式中的角色來解釋它們,好比是開發人員無法看到樹木的森林。我們需要能夠理解個體在整體中的角色,而不需要深入研究整體的細節。
“大規模結構”是一種語言,可讓您廣泛地討論和理解系統。一組高級概念或規則,或兩者都為整個系統建立了設計模式。這個組織原則可以指導設計和幫助理解。它有助于協調獨立的工作,因為有一個共同的概念:各個部分的角色如何塑造整體。
因此:
設計一種規則或角色和關系的模式,它將跨越整個系統,并且在不詳細了解該部分責任的情況下,允許對整個系統中的每個部分進行一些理解。
無設計的生產系統是沒有人能理解整體的,而且它們很難維護。但是,架構可以用預先設計的假設來約束一個項目,并且從應用程序特定部分的開發人員/設計人員那里獲得大量權力。很快,開發人員就會降低應用程序以適應結構,或者他們會破壞這個結構,并且根本就沒有任何結構,這就導致了不協調開發的問題。
因此:
讓這個概念性的大型結構與應用程序一起演進,可能會在過程中變成一種完全不同的結構類型。不要過度限制詳細的設計和模型決策必須要有詳細的知識。
當一個結構可以被發現的時候,就應該采用大規模結構【這2句不是很順,但也沒辦法了】,這樣就能在不違反模型開發的前提下,大大澄清系統。因為一個不合適的結構比沒有更糟糕,所以最好不要選擇全面性,而是尋找一個最小的集合來解決已經出現的問題。少即是多。
接下來是在一些項目中出現的四種特定模式的大規模結構,它們是這種模式的代表。
隱喻思維在軟件開發中非常普遍,特別是對于模型。但是,“隱喻”的極限編程實踐,使用隱喻為整個系統的發展帶來秩序已經成為一種特殊的方式。
軟件設計往往是非常抽象和難以理解的。開發人員和用戶都需要切實的方法來理解系統,并共享整個系統的視圖。
因此:
當一個與系統的具體類比出現時,它抓住了團隊成員的想象力,并且似乎將思維導向有用的方向時,把它作為一個大規模結構。圍繞這個隱喻組織設計,并將其吸收到通用語言中。系統隱喻既能促進關于系統的交流,又能引導系統的發展。這增加了系統不同部分的一致性,甚至可能跨越不同的限界上下文。
在面向對象的設計中,每個對象都被分配了一系列的相關職責。責任驅動設計也適用于較大規模。
當每個單獨的對象都有手工制定的職責時,沒有指導原則,不統一,也沒有能力一起處理大范圍的領域。為了實現一個大型模型的一致性,對這些責任的分配施加一些結構是有用的。
因此:
查看模型中的概念依賴關系,以及領域不同部分的變化率和變化源。如果你確定了領域中的自然層次,就把它們作為寬泛的抽象職責。這些職責應該講述一個關于您的系統的高級目標和設計的故事。重構模型,使每個領域對象、聚合和模塊的職責完全符合一個層的職責。
一組描述另一組對象應該如何表現的對象。
在一個應用程序中,實體之間的角色和關系在不同的情況下有所不同,復雜性可能會爆炸。既不是完全通用的模型,也不是用戶需要的高度定制的模型。對象最終引用其他類型來涵蓋各種情況,或者在不同情況下以不同方式使用的屬性。具有相同數據和行為的類可能只是為了適應不同的程序集規則而組裝。
因此:
創建一組可用于描述和約束基本模型的結構和行為的獨特對象。將這些關注點分為兩個“層次”,一個非常具體,另一個反映用戶或超級用戶能夠自定義的規則和知識。
(見Fowler,M.1997。分析模式:可重復使用的對象模型,Addison-Wesley。)
機會出現在一個非常成熟的模型中,并且是深入和精煉的。一個可插拔組件框架通常只有在幾個應用程序已經在同一個領域中實現之后才開始發揮作用。
當各種應用程序必須互操作時,所有的應用程序都基于相同的抽象,但是獨立地設計,在多個有界的上下文之間的轉換會限制集成。對于不緊密協作的團隊來說,共享內核是不可行的。復制和碎片化增加了開發和安裝成本,互操作性變得非常困難。
因此:
提煉接口和交互的抽象核心,并創建一個允許這些接口的各種實現自由替換的框架。同樣,允許任何應用程序使用這些組件,只要它嚴格地通過抽象核心的接口進行操作即可。
作者:Zachary_Fan
出處:http://www.cnblogs.com/Zachary-Fan/p/DDDReference7.html
如果你想及時得到個人自寫文章的消息推送,歡迎掃描下面的二維碼~。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。