Clean清潔領域模型的幾個特點 -Kamil Grzybek

19-11-01 banq
                   

如今,有關干凈代碼和體系結構的討論很多。關于如何實現它的討論越來越多。羅伯特·C·馬丁(Robert C. Martin)描述的規則是通用的,我認為,我們可以在其他各種情況下使用它們。

在本文中,我想讓他們參考領域模型實現的上下文,這通常是我們系統的核心。我們想擁有一顆干凈的核心,不是嗎?

從領域驅動設計方法可以知道,我們有兩個空間-問題空間和解決方案空間。Vaughn Vernon在DDD Distilled書中對這些空間的定義如下:

問題空間是您在給定項目的約束下執行高級戰略分析和設計步驟的地方。

解決方案空間是您實際實施問題空間討論確定為核心域的解決方案的地方。

因此,領域模型的實現是解決問題的方法。要討論領域模型是否干凈,我們必須首先定義清潔解決方案的含義。

什么是清潔解決方案

我認為每個人都對干凈解決方案的含義有所定義,或者至少感覺到自己所做的工作是否干凈。無論如何,讓我描述一下這對我意味著什么。

首先,指定的解決方案必須解決已定義的問題。這是強制性的。如果無法解決我們問題,即使是最優雅的解決方案,對于該問題空間而言也是一文不值。

其次,從時間的觀點來看,干凈的解決方案應該是最佳的。它應該花費的時間應該不超過或少于所需的必要時間。

第三,它應該是基于解決簡單問題的基礎上,以簡單性為前提,但要適應變化。我們應該始終保持平衡-不少(無設計或欠設計),也不多(過度設計,請參見YAGNI)。可以用Antoine Airman的Odyssey書中的一句話來總結:

所謂達到完美,不是沒有什么東西可添加了,而是再沒有什么東西可移除了

注意:當然,我們應該努力做到完美,因為要意識到我們將永遠無法實現它。

第四,我們應該根據他人的經驗解決問題,并從他們的錯誤中吸取教訓。這就是為什么架構和設計模式或原則如此有用的原因。我們可以采用某人的解決方案并使之適應我們的需求。而且,我們可以使用其他人創建的工具并使用它們。這是IT世界的顛覆者。

最后但并非最不重要的一點是對解決方案的理解程度。即使經過很長時間,我們也應該能夠理解我們的解決方案。更重要的是,其他人應該能夠理解它。該代碼讀起來比編寫的要多得多。馬丁·福勒說:

任何傻瓜都可以編寫計算機可以理解的代碼。好的程序員編寫人類可以理解的代碼。

總而言之,干凈的解決方案應在簡單時間與復雜性之間取得良好的平衡,從而在最佳時間內準確解決我們的問題。它應該基于其他經驗,常識,使用適當的工具來開發,并且應該易于理解。考慮到所有這些因素,我們如何確定我們的領域模型是一個干凈的解決方案?

Clean清潔領域模型

1.使用無所不在的統一語言

無處不在的語言是域模型中DDD戰略模式的基礎之一,在其中起著關鍵作用。好像是在編寫商業書籍一樣,商人或業務人士產品經理應該能夠理解所使用的所有邏輯,術語和概念,即使這是計算機程序,他們也無需掌握編程語言!如果我們在定義的上下文中到處使用相同的語言,概念和含義,那么大家就容易對領域的問題空間及其解決方案增加理解,只會增加項目成功的可能性。

2.行為豐富

顧名思義,領域模型(Domain Model)對領域進行建模。我們在領域中有行為,因此我們的模型也應該有它。如果沒有這種行為,我們將處理所謂的“?貧血域模型”反模式。對我來說,這實際上是一個數據模型,而不是領域模型。這種模型有時很有用,但當我們具有復雜的行為和邏輯時卻沒有用。它使我們的代碼具有程序性,并且面向對象編程的所有好處都消失了。真正的領域模型具有豐富的行為。

3.被封裝

封裝的領域模型是非常重要的。我們只想向外界公開有關我們模型的最少信息。我們應該防止業務邏輯泄漏到我們的應用程序邏輯,甚至更糟– GUI。理想情況下,我們應該只在聚合上公開公共方法(領域模型僅有的輸入渠道)。

4.持久性是無感的

持久性無感(PI)是領域模型的另一個眾所周知的概念和理想屬性。我們不想在模型和持久性存儲之間建立高度的耦合。這些是不同的概念,任務和責任。一件事的改變對另一件事的影響應該最小,反之亦然。該區域的低耦合意味著我們的系統可以更好地適應變化。

5.堅持SOLID原則

由于領域模型是面向對象的,因此應遵循所有SOLID原則。例子:

  • SRP –一個實體代表一個業務概念。一種方法可以做一件事。一個事件代表一個事實。
  • O / C –業務邏輯實現應易于擴展而不更改其他位置。在這種情況下,最常使用策略/策略模式
  • LSP –由于堅持繼承規則組成,遵守LSP規則應該很容易。繼承是類之間的最強耦合,這是我們要避免的
  • ISP –我們的域服務或策略的接口應較小–理想情況下應采用一種方法
  • DI –要使我們的域模型與其余應用程序和基礎結構脫鉤,我們需要使用依賴注入和依賴倒置原理。這種組合為我們提供了強大的武器–我們可以在模型中保持一定的抽象水平,在整個模型中使用業務語言,并隱藏技術實現細節。

6.使用領域原語

我看到的大多數代碼庫都對基本類型進行操作-字符串,整數,小數和guid。在領域模型中,此抽象級別絕對太低。

我們應該始終嘗試使用類(實體或值對象)來表達重要的業務概念。通過這種方式,我們的模型更具可讀性,易于維護,行為豐富。另外,我們的代碼更加安全,因為我們可以在類級別添加驗證。您可以在此處閱讀有關域基元的更多信息。

7.高效

即使是寫得最好的領域模型,也無法在令人滿意的時間內處理請求,這是沒有用的。這就是為什么實體大小和集合邊界如此重要的原因。

在設計聚合時,您需要知道如何處理它們–多久一次,有多少用戶將嘗試同時使用它們,是否會增加活動周期等等。聚合越小,需要加載和保存的數據越短,事務也就越短。另一方面,總量越小,一致性邊界就越小,因此需要正確的平衡。

8.富有表現力

面向對象語言的類結構是對業務概念進行建模的強大工具。不幸的是,它經常被錯誤地使用。最常見的錯誤是用一個類對許多概念進行建模。為此(通常不自覺地)使用狀態和數據位標志。

通常,此類可以分為幾個類別,這些類別支持SRP。這里的一種啟發式方法是研究業務語言并研究我們實體的行為。

9.可測試和測試

領域模型用于解決復雜的問題。復雜的問題意味著需要復雜的業務邏輯來解決。如果您有復雜的解決方案,則必須確保它能夠正確運行,并且不必擔心更改此邏輯。

這是單元測試輸入的地方,這是干凈的Domain Model的組成部分。干凈的領域模型是可測試的,應該有一個最大的測試覆蓋因素。這是我們應用程序的核心,我們應始終百分百確保它能夠按預期工作。

10.應該輕松編寫

這是以上所有內容的總結。如果每次都編寫域模型代碼是一個問題-很難更改,理解,測試,使用它-出現問題。你應該怎么做?

查看我上面描述的所有要點,看看您的模型不符合什么條件?也許取決于基礎架構?也許他說的是非商業語言?也許是貧血,封裝不良或無法測試?如果您的模型滿足本文中描述的所有屬性,那么解決業務問題應該輕松而愉快。我向你保證。

所以我有一個問題–今天您是通過編寫業務邏輯來放松一下,還是再次碰壁?您的領域模型干凈嗎?

?

                   

2
美女漫画大全