領域描述與模型組成

領域層是實踐領域驅動設計理論的核心,這一個概念層管理描述領域知識的模型物件,以及其它相關的服務物件,同時透過聚合概念組織模型。應用程式發展的過程中,開發人員透過與領域專家協同合作,經由塑模程序完成模型的建立,並且以程式碼完成模型實作。

模型用來描述領域知識,因此們根據所要解決的領域問題,建立所需的模型架構,而模型主要由實體(Entities)與實值物件(Value Objects)等兩種類型的物件組成,類別封裝領域知識以支援相關的實作,實體與實值物件的差異,在於實體必須是一個具備識別資訊的類別物件,而實值物件則僅封裝某個特定的資料值,本身並不需要識別資訊。

以訂單程序為例,一筆完整的訂單包含單一的主檔,以及多筆相關的明細資料,為了處理商品訂購的交易流程,我們設計類別封裝相關的資訊,來看看最簡單的訂單架構:


根據圖示結構,我們需要以下表列的實體,封裝其中的資訊:

實體說明
Order訂單主檔資訊與配送資訊
Customer客戶資訊
OrderLine訂單明細檔資訊
Product商品資訊

整合表列的實體,即可建構商業流程來處理商品交易程序,並且將相關的資訊封裝於以實體命名的類別,例如Order類別,每一個實體都必須要有識別資訊,在類別中以屬性定義,例如 OrderID 屬性,其它的實體則逐步定義即可。

在訂單主檔中有一塊「配送資訊」,通常包含訂單配送的地址以及聯話電話等資訊,這些資訊可能與客戶資訊相同,也可能是這一張訂單專屬的特定配送資訊,這一類的資訊通常合併為訂單主檔的一部份,且我們只關注其中封裝的值。

為了軟體設計的彈性並簡化結構,「配送資訊」的內容通常建議切割出來,封裝為獨立物件,而這個物件附屬於Order,因此不需要識別資訊,以實值物件進行設計,這是與實體最大的差異。

通常在於需要封裝一組以上的相關資訊時,才會定義封裝資料的實值物件,例如我們定義一個類別AddressInfo來封裝關於配送地址的資料,其中會包含國家、區、路名以及號碼等等,然後透過定義AddressIfno型別的屬性,接受 AddressInfo 物件,而電話等簡單的型別的資料,則直接以屬性儲存即可。

由於AddressIfno物件會直接被設定至 Order 實體,成為其部份內容,因此本身並不需要識別資訊,這個物件在離開Order 實體之後,就沒有存在的意義,另外如果需要調整地址配送資料,則重新建立AddressIfno物件即可,這是實值物件的另外一個特性,一旦建立之後就不會進行更動,在需要的時候直接建立新的物件取代。



沒有留言: