從何處開始做域模型？

Question

假設我已經制作了一個概念列表，用於繪製我的域模型。此外，我有幾個使用案例，我從中做了幾個系統序列圖。

當繪製域模型，我從來不知道從哪裏開始：

1. 設計模型，因爲我相信該系統能。這就是說，如果我爲人體建模，我首先要添加心臟，大腦，腸，胃，眼睛，頭等的類概念。
2. 從設計用例需要完成的工作開始。這是，如果我有一個用例是有關使人體吞的東西，我會先畫了口腔，咽喉，Stomatch，通腑等

中，我做的順序類概念事情是不相關的？我認爲最好從用例概念設計出來，因爲它們通常是你想要處理的內容，而不是其他類型的概念，雖然有助於描述整個系統，但很多時候可能會目前的項目甚至不需要。我還沒有考慮其他方法嗎？你通常如何處理這個問題？

謝謝

Answer 1

我首先繪製一個具有所有關係的類圖，並根據您的應用程序的要求僅實現必需的類。

您可以使用貧血的方法（屬性加getter和setters）來保持簡單並避免在同一步驟中編寫業務邏輯的步驟。使用貧血模型時，邏輯將進入相應的Service類。這樣你可以稍後考慮用例。

我知道有些人不喜歡這種做事方式，但它確實有助於維護並避免一些依賴性問題。

答到吞噬極樂世界的問題，下面：

在分析方面，從使用情況下（什麼），然後繼續到類圖（如何）聽起來像一個很好的經驗法則。就個人而言，之後我會做序列圖（何時和誰？），因爲您需要知道哪些進程/對象消息需要發送。 （除了Merise，RAD，RUP，Scrum等），UML只是模擬系統/項目的一種方式，而不是一種方法。只要有足夠的信息來完成任何圖表，就沒有任何東西阻止某人開始使用任何圖表。事實上，它們應該同時完成，因爲每個圖都是同一個系統/項目的不同視角。

總而言之，這取決於你如何進行分析。在我的學習期間，我學習了剛性瀑布方法，在開始生成一些代碼之前，您可以從頭到尾做完整的分析。然而，事情在實踐中可能會有所不同，因爲必須儘可能在最短的時間內生成工作應用程序。

例如，最近我介紹了一個Scrum方法，其中涉及創建一個網站，人們可以發佈他們的小說。由於時間有限，並且我們對應該達到的目標有清晰的認識，我們立即開始用骨骼類圖來表示domain model。然後從我們製作的一系列模擬屏幕中推導出用例。

從內存中，類是故事，章節，用戶和類別。最後一節課被淘汰，以支持更靈活的Tag類。正如您想象的那樣，由於應用了領域驅動設計和Java編程語言的特性，現有項目的完整類圖將會更加複雜。

這種方法可能被視爲馬虎。然而，像這樣的網站可以使用迭代過程在幾周內輕鬆完成，並且仍然設計得很好。迭代過程優於瀑布方法的優點是您可以隨時隨地調整需求。頻繁的需求變化是一個現實，因爲人們經常會改變主意，並且在每次迭代後都可以生成一個工作應用程序，從而讓人們可以繼續講課。

當然，當您向客戶展示項目時，使用UML圖表和一些模擬屏幕進行完整的分析將是更可取的，因此他們可以瞭解您提供的內容。這就是UML的用途。一旦你解釋了一些可視化約定，一個人應該能夠理解這些圖表。

最後，如果您處於您想要確定客戶需求的情況下，逐步建立您可以隨身攜帶的調查問卷可能是一個好主意。採訪一個人是唯一可以確定應用程序真正需要哪些概念/功能的方法，並且您應該回過頭來澄清某些方面。另一個提示是當你遇到你不熟悉的主題時，在網上做一些快速的研究。

在你的例子中，這將是通過解剖學的基礎知識。除此之外，這將幫助你決定模型應該包含什麼以及它應該具有什麼粒度（應該考慮哪一組器官？它需要多精確？只有器官需要建模或者應該分解成他們的成分如組織，細胞，化學成分等？）。

Answer 2

我覺得開始的地方會是任何合乎邏輯和舒適的地方。最好從用例開始，因爲它們給你明確的方向和目標，並幫助你避免YAGNI的情況。鑑於您應該嘗試開發一個強大的領域模型，因爲整個領域的情況非常重要，所以這並不重要。

Answer 3

無論是否DDD，我都會建議通過訪問產品所有者來確定無處不在的語言（UL）。以一種讓你和產品擁有者說同一種語言的方式建立溝通不僅是溝通的助手，而且能夠用通常的術語討論項目往往有助於領域模型定義自己。

所以，我的答案基本上是討論，傾聽和學習。軟件滿足需求。從專家的角度理解模型將爲應用奠定堅實的基礎。

Answer 4

我想分享我在這種情況下的經驗。我通常從編寫測試和代碼開始。並嘗試涵蓋一個端到端的用例。這給了我足夠的關於問題的想法，最後我還有一些與我合作的東西，我可以向我的客戶展示案例。大多數時候，後續故事都是建立在前一個故事的基礎之上，但是後來的故事也需要在前一個模型中進行更改。但這並不影響我，因爲我已經有了很好的測試覆蓋率。通過這種方式，我提出了適合當前問題的模型，而不是映射現實世界的模型。

Answer 5

您從可以正式化或不正式的業務需求開始。如果形式化，你會使用用例圖。

例如這裏是一個電子商務應用用例圖： http://askuml.com/blog/e-commerce/

http://askuml.com/files/2010/07/e-commerce-use-case.jpg http://askuml.com/files/2010/07/e-commerce-use-case2b.jpg

從這些用例，你自然可以推斷出實體企業：產品，產品類別，購物車，...開始準備班級圖表。

這是許多方法中的最佳實踐，但這也只是常識和自然。

Answer 6

短的答案

選擇一個用例，得出了一些協作圖（和類圖）來實現所涉及的域對象。只集中於那些爲了完成用例目標而參與的對象。編寫TDD測試用例來設置期望值，並逐漸爲您的域類建模以滿足期望。 TDD對理解預期行爲非常有幫助，並有助於獲得更清晰的域模型。您將看到您的域名隨着TDD的期望而逐漸演變。

龍答案

我與DDD個人的經驗是不容易的。那是因爲我們首先沒有必要的基金會。我們的團隊在不同領域有很多薄弱環節;要求沒有得到妥善處理，我們只有一位客戶代表，他沒有真正幫助（不參與）。我們沒有適當的發佈計劃，開發人員缺乏面向對象的概念，最佳原則等等。我們遇到的主要問題是花費了太多時間來試圖理解域邏輯。我們勾畫了許多類圖，並且我們從來沒有正確的領域模型，所以我們停止了這樣做，並發現出了什麼問題。問題在於我們太過努力去理解領域邏輯，而不是溝通我們根據需求制定了假設。我們決定改變我們的方法，我們應用了TDD，我們開始編寫預期行爲並編寫域模型以滿足TDD的期望。有時候我們因爲不理解域而被寫入TDD測試用例。我們馬上和客戶代表交談，並試圖獲得更多的意見。我們改變了發佈策略;應用敏捷方法並經常發佈，以便我們從最終用戶那裏得到真正的反饋。但是，需要確保最終用戶的期望值設定在正確的水平。我們根據反饋進行重構，並以這種方式逐漸演變出領域模型。隨後，我們應用設計模式來提高可重用性和可維護性。我的觀點是DDD本身無法生存，我們必須建立一個包含領域的生態系統，開發者必須擁有強大的面向對象的概念，並且必須欣賞TDD和單元測試。我會說DDD位於所有OOP技術和實踐之上。