「分而治之」這個名字對於報紙的佈局來說沒有任何意義。
沒有人能解釋該功能的作用或為什麼要使用它。
沒有人要求這個功能，也沒有人想要它。
本質上，更多的注意力放在該計劃可以做什麼，而不是考慮為什麼應該這樣做。
領域驅動設計 (DDD) 是一種軟體開發方法，重點是充分理解軟體將應用的領域。當您了解該領域時，您就可以降低新增客戶不需要或不想要的功能的風險。
什麼是領域驅動設計（DDD）？
軟體旨在讓我們的生活更輕鬆。它可以簡化和自動化現實世 新加波电话号码 界的流程，或解決特定使用者感興趣的領域。軟體所涉及的事物是軟體預期工作的領域。
一位名叫 Eric Evans 的軟體開發人員意識到了解軟體領域的必要性。為了介紹 DDD 方法，他寫了一本名為「領域驅動設計：解決軟體核心的複雜性」的書。埃文斯在他的書中說：「軟體的核心是它為用戶解決領域相關問題的能力。所有其他功能，儘管可能很重要，但都支持這一基本目的。
因此，在上面的報紙佈局範例中，您不需要成為專業的佈局編輯器來設計有用的佈局軟體。但是，如果您想製作反映實際流程和程序的軟體，您確實需要了解佈局編輯器如何完成其工作。任何超出他們需要的功能幾乎沒有價值。
領域驅動設計的指導原則
基本上，領域驅動設計是關於開發對現實世界的系統和流程進行建模的軟體。此方法基於以下 DDD 指導原則：
專注於核心領域：在開始編碼之前，與該領域的工作人員交談。它們可以幫助您定義該領域的所有流程、流程和術語。例如，如果您正在設計管理零售庫存的軟體，請與管理商店庫存的人員而不是人力資源或財務人員交談。
透過基於領域模型進行設計來降低複雜性：當您了解業務領域時，請建立一個反映現實世界領域的模型。例如，您的庫存管理軟體應包括對庫存經理來說很重要的功能，例如庫存趨勢分析、自動補貨、條碼掃描等。模型是表示領域專家知識的組織和抽象的圖表、圖表或書面段落。
說通用語言：埃文斯在他的書中談到了通用語言的重要性。參與該專案的每個人都應該使用相同的語言來討論該領域。聆聽領域專家使用的單字和片語。在需求文件、模型和程式碼本身中採用相同的術語。
關鍵領域驅動設計術語
以下常見關鍵術語對學習 DDD 很有幫助：
領域邏輯：也稱為業務邏輯。這就是模型和軟體設計的目的。該設計基於現實世界業務規則的邏輯，這些規則被轉換為程式碼。
設計模式：如果現有程式碼可以解決與您正在處理的問題類似的問題，請對其進行調整以供您使用。不要每次都嘗試重新發明輪子。
上下文：決定軟體領域內單字、操作或功能的含義的設定或環境。例如，在特定上下文中，使用“應用”按鈕而不是“儲存”按鈕可能更有意義。
有界上下文：大型專案通常有許多需要整合的模型。上下文邊界定義了模型可以在其中演化的邏輯架構。這有助於其他團隊了解他們必須做什麼才能使他們的模型在添加到其他團隊時有效。
上下文映射：概述多個有界上下文之間關係的文檔、圖形或圖表。此映射顯示了每個上下文的語言、獨立實作以及用於與其他有界上下文通訊的介面。
實體：實體是由其唯一識別碼而非屬性定義的域物件。例如，一個人買票去看電影。人是一個實體，因為唯一標識符定義了該人是誰，無論頭髮顏色、體重、身高等如何變化。
值物件：具有屬性但沒有明確標識的不可更改的物件。例如，您購買的電影票不包含指定座位。劇院裡所有的座位都是一樣的。座位是用螺栓固定的，不能移動，但你的票可以讓你選擇任何可用的座位。在這種情況下，座位就是一個價值對象。
領域驅動設計的優點
DDD 最明顯的優點是它讓每個人都使用相同的語言。當開發團隊使用與領域專家相同的語言時，就會產生對最終用戶有意義的軟體設計。由於應用程式中的術語與現實世界的活動相對應，因此混淆較少，用戶將更快地了解如何使用該產品。
DDD 的其他好處包括：
業務和開發是一致的：由於使用相同的語言，開發人員在與業務團隊交談時可以更好地溝通和理解。這種一致性降低了開發團隊和領域專家之間混淆和誤解的風險。
保護領域知識：當團隊轉向其他專案以及引入新人員來維護現有專案時，寶貴的知識不會遺失。
更大的靈活性：情境定義和邊界使處理需求變更變得更容易，因為每個人對業務領域都有相同的理解。
易於追蹤：更好的溝通和一組通用術語使追蹤需求實施變得更加容易。
更好的應用程式平衡：有時過度強調軟體的 UX/UI。這些很重要，但如果忽略某些領域要求，可能會導致麻煩。如果你的程式不能做使用者想要它做的事情，那麼它再漂亮也無濟於事。專注於解決領域的需求和領域專家的建議，以便最終的軟體能夠平衡以滿足客戶的需求和期望。
更好的程式碼：遵循 DDD 方法最終會為您帶來更乾淨、更可靠的程式碼。它還可以建立可重複的最佳實踐和設計模式，使未來的專案運作更加順利和有效率。
