1. 程式人生 > >(DDD)領域驅動設計——認識領域驅動

(DDD)領域驅動設計——認識領域驅動

什麼是領域Domain?

理解DDD,首先要理解領域。

通俗的說,領域就是業務;就是合格的產品經理的需求文件所表達的內容;狹義的說就是你的Business Layer裡所有的程式碼以及產生的影響等等;

嚴謹的定義是:

一個有邊界的業務面,其中包含業務概念,業務行為,業務影響。計算機程式應用於這個業務面,並使得程式具有實際的商業價值,賦予程式實際意義。

域中可以再劃分為子域,並且域與域之間一般存在聯絡。不做展開,後文詳述。如下,就是一個無人機交付系統的領域草稿:

在這裡插入圖片描述

DDD 的價值

  • DDD 使領域專家與開發人員成為密不可分的團體。

領域專家:精通業務的任何人,不侷限於崗位。

領域專家與開發人員通過一套適用於當前領域建模的“通用語言”進行交流溝通,並且持續更新這套語言。“通用語言”是對軟體模型的直接反映。

  • DDD 關注業務戰略
    DDD的戰略設計在於明確地界限,區分不同系統與業務關注點。這樣可以保護每個業務層面的服務,是實現SOA或微服務架構的有力保障。
  • DDD 是領域建模的工具
    這些戰術上的工具保障了開發人員能夠按照領域專家的思維模型設計開發軟體,也迴歸了面向物件的思想。並且保障開發出的軟體是可測試的、良好伸縮性、健壯性、並且允許分散式。

總而言之,DDD不是一種技術,也不侷限與一種開發語言。他是一種指導思想(戰略),並提供具體的工具(戰術)。從立項到持續交付之間的漫長時間中,保障專案的團隊高效,軟體易擴充套件、健壯、穩定。

接下來,我們通過一個常見的不合理設計示例體會DDD思想。

貧血領域物件

@Transactional
public void saveCustomer(
	String customerId,
	String customerFirstName, String customerLastName,
	String streetAddress1, String streetAddress2,
	String city, String stateOrProvince,
	String postalCode, String country,
	String homePhone, String mobilePhone,
	String primaryEmailAddress, String secondaryEmailAddress) {
	Customer customer = customerDao.readCustomer(customerId);
	
	if (customer == null) {
	customer = new Customer();
	customer.setCustomerId(customerId);
	}
	
	customer.setCustomerFirstName(customerFirstName);
	customer.setCustomerLastName(customerLastName);
	customer.setStreetAddress1(streetAddress1);
	customer.setStreetAddress2(streetAddress2);
	customer.setCity(city);
	customer.setStateOrProvince(stateOrProvince);
	customer.setPostalCode(postalCode);
	customer.setCountry(country);
	customer.setHomePhone(homePhone);
	customer.setMobilePhone(mobilePhone);
	customer.setPrimaryEmailAddress(primaryEmailAddress);
	customer.setSecondaryEmailAddress (secondaryEmailAddress);
	customerDao.saveCustomer(customer);
}

理解領域、子域、界限上下文

領域從廣義上來講,通常包含了過多的資訊,可能一個公司所有的業務都可以用某某領域概括。但是對於開發,我們需要把這個領域拆分為多個子域,並且子域之間存在明確的界限。

待續。。。。

相關推薦

(DDD)領域驅動設計——認識領域驅動

什麼是領域Domain? 理解DDD,首先要理解領域。 通俗的說,領域就是業務;就是合格的產品經理的需求文件所表達的內容;狹義的說就是你的Business Layer裡所有的程式碼以及產生的影響等等; 嚴謹的定義是: 一個有邊界的業務面,其中包含業務概念,業務行

DDD領域驅動設計領域事件

# 1 前置閱讀 在閱讀本文章之前,你可以先閱讀: * DDD領域驅動設計是什麼 * DDD領域驅動設計:實體、值物件、聚合根 * DDD領域驅動設計:倉儲 * MediatR一個優秀的.NET中介者框架 # 2 什麼是領域事件? 領域事件是在領域中發生的事,你希望同一個領域(程序)的其他部分了解它。 通知

【轉】領域驅動設計領域模型

領域驅動設計之領域模型 加一個導航,關於如何設計聚合的詳細思考,見這篇文章。 2004年Eric Evans 發表Domain-Driven Design –Tackling Complexity in the Heart of Software (領域驅動設計),簡稱Evans DDD。領域驅動設計

EF Code first 和 DDD (領域驅動設計研究)系列一

發的 tex bsp cti 設計 ron 映射 developer devel 在上個公司工作時,開發公司產品的過程中,接觸到了EF Code first. 當時,整個產品的架構都是Lead developer設計建立的,自己也不是特別理解,就趕鴨子上架跟著一起開發了。

領域驅動設計DDD)- 請先搞清楚一些概念

責任 可能 升級 是你 ora ext 計數 方法 避免 開發一個新系統   一般我們開始開發一個商業系統都需要做什麽?讀需求文檔去查找功能點,拆解任務。多數情況下,拆解項目是為了評估工作,做評估、分配任務到個人、設計數據庫結構,然後就開始了Coding。 所以,這種方

DDD領域驅動設計實踐 —— 架構風格及架構實例

讀取 bili 邏輯 stat orcal ransac 應用服務 業務場景 解讀 概述 DDD為復雜軟件的設計提供了指導思想,其將易發生變化的業務核心域放置在限定上下文中,在確保核心域一致性和內聚性的基礎上,DDD可以被多種語言和多種技術框架實現,具體的框架實現需要根據

DDD領域驅動設計實踐 —— 限界上下文識別

團隊協作 協作 tin 組織 領域 ges 承擔 產品 進行 本文從戰略層面街上DDD中關於限界上下文的相關知識,並以ECO系統為例子,介紹如何識別上下文。限界上下文(Bounded Context)定義了每個模型的應用範圍,在每個Bounded Context中確保領域模

領域驅動設計(DDD:Domain-Driven-Design)

因為我司框架是基於DDD+外掛的模式,基於學習需要所以初步學習了DDD,並且請教了DDD的專家寬寬大佬. DDD定義:領域模型應該捕抓“業務規則”或者“領域邏輯”(business rules/domain logic),而應用模型則捕抓“應用邏輯”(a

.NET領域驅動設計—看DDD是如何運用設計模式顛覆傳統架構

閱讀目錄: 1.開篇介紹 2.簡單瞭解緣由(本文的前期事宜) 3.DomainModel擴充套件性(運用設計模式設計模型變化點) 3.1.模型擴充套件性 3.2.設計模式的使用(苦心專研的設計模式、設計思想可以隨意使用了) 3.3.部分類的使用(封裝內部物件) 3.4.高強度的OO設計(

領域驅動設計DDD)在美團點評業務系統的實踐

點選上方藍字訂閱,不錯過下一篇好文章本文轉自美團點評技術公眾號:meituantech前言至少3

領域驅動設計(DDD:Domain-Driven Design) 侵立刪

轉自:https://www.jdon.com/ddd.html   領域驅動設計(DDD:Domain-Driven Design)   Eric Evans的“Domain-Driven Design領域驅動設計”簡稱DDD,Evans DDD是一套綜合軟體系統分析和設計的

DDD領域驅動設計實踐 —— 框架實現

本文主要了在社群服務系統(ECO)中基於SpringMVC+mybatis框架對DDD的落地實現。本文為系列文章中的其中一篇,其他內容可參考:通過業務系統的重構實踐DDD。 框架實現圖 該框架實現基本和DDD的指導思想契合,主要分為四層,且將關注點放在了domain層。下

關於領域驅動設計DDD)中聚合設計的一些思考

關於DDD的理論知識總結,可參考這篇文章。 DDD社群官網上一篇關於聚合設計的幾個原則的簡單討論: 聚合是用來封裝真正的不變性,而不是簡單的將物件組合在一起; 聚合應儘量設計的小; 聚合之間的關聯通過ID,而不是物件引用; 聚合內強一致性,聚合之間最終一致性; 上面這幾條原則,作者通過

DDD領域驅動設計

去除一切花俏的建模技巧,我覺得最重要的方向就是去努力分析問題和事物的本質,針對這個本質進行領域建模。這個領域建模,最主要的還是鍛鍊的人的事物抽象能力。10個人,建出來的領域模型都不同。本質原因就是大家對同一個問題的理解不同,對事物的本質的理解不同。雖然最終都能解決當前的問題,但是對適應未來需求變化的能力卻

淺談我對DDD領域驅動設計的理解

從遇到問題開始 當人們要做一個軟體系統時,一般總是因為遇到了什麼問題,然後希望通過一個軟體系統來解決。 比如,我是一家企業,然後我覺得我現線上下銷售自己的產品還不夠,我希望能夠在線上也能銷售自己的產品。所以,自然而然就想到要做一個普通電商系統,用於實現線上銷售自己企業產品的目的。 再比如,我是一家網際網

領域驅動設計DDD)部分核心概念的個人理解

領域驅動設計(DDD)是一種基於模型驅動的軟體設計方式。它以領域為核心,分析領域中的問題,通過建立一個領域模型來有效的解決領域中的核心的複雜問題。Eric Ivans為領域驅動設計提出了大量的最佳實踐和經驗技巧。只有對領域的不斷深入認識,才能得到一個解決領域核心問題的領域模型。如果一個應用的複雜性不是在技

C#進階系列——DDD領域驅動設計初探(六):領域服務

前言:之前一直在搭建專案架構的程式碼,有點偏離我們的主題(DDD)了,這篇我們繼續來聊聊DDD裡面另一個比較重要的知識點:領域服務。關於領域服務的使用,書中也介紹得比較晦澀,在此就根據博主自己的理解談談這個知識點的使用。 DDD領域驅動設計初探系列文章: 一、領域服務的引入 在《領域驅動設計:軟體核

C#進階系列——DDD領域驅動設計初探(四):WCF搭建

前言:前面三篇分享了下DDD裡面的兩個主要特性:聚合和倉儲。領域層的搭建基本完成,當然還涉及到領域事件和領域服務的部分,後面再專案搭建的過程中慢慢引入,博主的思路是先將整個架構走通,然後一步一步來新增相關元素,使架構慢慢變得豐滿。這篇打算分享下應用層的搭建。根據DDD的設計原則,應用層不包含任何領域邏輯,它主

C#進階系列——DDD領域驅動設計初探(五):AutoMapper使用

前言:前篇搭建了下WCF的程式碼,就提到了DTO的概念,對於為什麼要有這麼一個DTO的物件,上章可能對於這點不太詳盡,在此不厭其煩再來提提它的作用: 從安全上面考慮,領域Model都帶有領域業務,讓Client端引用Domain Model就意味著Client端可以繞過應用層直接完成業務邏輯的呼叫,這樣

C#進階系列——DDD領域驅動設計初探(三):倉儲Repository(下)

前言:上篇介紹了下倉儲的程式碼架構示例以及簡單分析了倉儲了使用優勢。本章還是繼續來完善下倉儲的設計。上章說了,倉儲的最主要作用的分離領域層和具體的技術架構,使得領域層更加專注領域邏輯。那麼涉及到具體的實現的時候我們應該怎麼做呢,本章就來說說倉儲裡面具體細節方便的知識。 DDD領域驅動設計初探系列文章: