領域驅動設計裡有很多東西，我們可以應用在各種各樣的開發模式裡，所以接下來說的一些東西，我們可以部分使用。
說道領域驅動的領域，大家肯定就要開始說bounded context,聚合，聚合根，容易讓大家搞糊塗。 我覺得先拋開這些概念，後面再來說如何設計聚合，先簡單來說。
過去，我們在多層設計裡定義了很多model, 資料庫的model(db entity), 然後為了不依賴資料庫，我們有設計了業務的domain model, 同時我們又設計了viewmodel, 這樣一般也沒什麼問題，職責也很清晰。但是有幾個問題
領域模型成了乙個單純的dto了。
首先我們要看領域，就是我們盡量把業務聚合到乙個領域裡，比如我們要做乙個功能，可以看到使用者每一次的登入日誌，那個這個登入日誌其實就是屬於使用者這個領域裡。
其次我們看模型，原來我們的模型都是只有屬性，也就是貧血模型，貧血的意思就是沒有行為，像木乃伊一樣，但是實際上領域是我們要完成業務的最主要的地方，我們希望領域能夠自製，也就是領域自己管理自己。
比如有乙個employee, 他的狀態有active, pending, deactive, 業務上是pending只能改為active.
```c#
public class employee : entity
public employeestatus employeestatus
}```
```c#
public class employeeservice : iemployeeservice
public void changestatus(employeestatus status, guid employeeid)
}}```
```c#
public class employee : entity
public employeestatus employeestatus
public void changestatus(employeestatus status)
this.employeestatus = status;
}}public class employeeservice : iemployeeservice
public void changestatus(employeestatus status, guid employeeid)
}}```
其實領域驅動設計最難的就是設計領域(domain), 也就是後面會說到的aggregateroot 聚合，但是我想我們先讓領域不再貧血，這樣在傳統的多層設計，資料驅動等架構都可以使用這種模式。
領域驅動設計系列（一） 為何要領域驅動設計？
領域驅動設計最近貌似開始火起來了，越來越多的人開始認識到領域設計的重要性，從我做過的專案來看，似乎歐洲已經有很多的公司開始實施領域驅動設計了，我看領域驅動設計也有些時間了，但是網上不管是文章還是 都顯得太過 高大上 一談領域驅動設計，一大堆的概念一股腦的給你上上來，搞的有點暈頭轉向，而我想在一些中小...
DDD領域驅動設計 充血模型 貧血領域模型
最早廣泛應用源於ejb2，最強盛時期則是由spring創造，把 分離到不同的物件中 貧血領域模型是乙個存在已久的反模式，它不是個好東西。它完全和物件導向設計背道而馳。物件導向設計主張將資料和行為繫結在一起，而貧血領域模型則更像是一種面向過程設計。貧血領域模型的根本問題在於，它引入了領域模型設計的所有...
領域驅動系列四之模型驅動
1 常規以類圖作為領域模型開發存在的問題 傳統型以技術為驅動的團隊,往往喜歡通過類圖來展示產品的模型,這樣的模型往往存n個物件,這些物件往往存在複雜的關聯,產品的創始人,可能能理解整個產品的架構思路,但是如果是新成員,想通過類圖去了解該產品,那幾乎是不可能的.往往最後還是需要領域專家進行溝通,在結合...