Tactical patterns

ddd的作用是控制系統複雜度，確保領域模型簡潔。模型用來表達模型的含義，關係，邏輯。

每個用於搭建框架的模塊，都有自己單一的職責；在領域模型裏面等價於entity或value object。不受生命週期中factory，repository的干擾。

可以使用組件，創建domain模型。

Patterns to Model Your Domain

以下模式代表問題域的策略和邏輯。表達了對象，模型規則，並將分析模型的細節綁定到代碼實現模型。

如下介紹的是代碼中的模型元素。

Entities

entity的概念是由身份定義，而不是屬性。即使entity包含整個生命週期，它的屬性可能改變。entity的責任是負責定義跟它行爲類似的類。在代碼裏面，可以通過繼承來實現這個類。（個人感覺，entities有點類似平時用的實體，或者實體的父類，不僅僅有屬性，還有豐富的方法表示它的行爲）

Value Objects

value objects爲代表包含domain特性的元素或者概念；它們用來描述模型；用來描述模型裏面的元素；它們不需要獨特的身份。因爲value objects 在模型中，沒有概念上的認同，它們被定義爲屬性，這些屬性決定了它的行爲。value objects不需要身份，因爲它經常在特定背景下跟其他的對象相關聯。舉個例子，有個order entity 使用value objects 代表order的address, items, courier information。它不需要特定的身份，它內容直接關聯order。order的address如果不跟order關聯起來，完全沒有意義。value objecs基於orders的屬性，就像實體自帶equal檢查。

因爲value objects根據他們的特性定義，value objects被認爲一成不變的；也就是說，一旦被構造創建，它們將永遠不會更改它的狀態。一個好的例子就是money，不需要區分口袋裏面錢的多少。不需要關注貨幣的身份，只需要關注它的值和它代表的含義。如果有人想跟你交換一個5$，事實仍舊擁有5$。當然，在現實生活中，錢可以擁有獨特的身份id，但是領域模型並沒有影響真實的生活。相反，它是對它的抽象，旨在滿足問題域內用例的需求。

Domain Service

Domain services封裝domain的邏輯和概念，既不是entity，也不是value object。Domain services 既沒有身份，也沒有狀態；它的職責是編排調度entity和value object的邏輯。

Modules

用它組織和封裝相關概念(entities和value objects)。用來簡化對大的domain models的理解。modules讓開發者很快閱讀，理解domain model，方便查找。(其實就是放entities和value objects的文件夾)

LifeCycle Patterns

這個模式用於創建，持久化 domain objects。

Aggregates

entities和value objects共同構成domain model，並滿足不變性。在處理對象的大型互連關聯時，通常難以確保對域對象執行操作時的一致性和併發性。

domain driven design 通過Aggregates 確保一致性和定義事務實時性。大的models被分割成不變的部分，以及分爲實體和價值對象的集合，這些實體和價值對象被視爲概念整體。

多個aggregate通過id之間互相關聯，既創建了關聯，也避免了冗餘不必要的大對象。

Factories

如果創建entity或者value object非常複雜，需要委託給factory的構造函數。factory確保所有的不變在domain object創建之前初始化完成。如果domain object很簡單，沒有什麼特別的規則對於有效的構造函數，優先採用構造函數而不是factory。可以使用factories重複創建domain objects從持久存儲裏面。