在領域設計中，劃分為三種模型，分別為：實體(Entity)、值對象(Value Object)、和服務(Service)。其中Service與我們傳統設計中的Service有什么不同呢？
讓
我們來回憶一下，通常我們針對將讀寫xml、資金轉賬等代碼放在service中，可以看出，該層包括了兩種含義，一種是與業務無關的，一種是與業務緊密
關聯的。領域驅動設計將這兩層含義進一步劃分，《Domain-Driven
Design》中的例子那樣：如果銀行應用可以將我們的交易轉化并輸出電子表格文件，那么這種輸出就應該是應用服務。而負責處理資金轉帳的借貸關系，應該
屬于領域層，它包括了基本的業務邏輯，而技術層上的服務則根本沒有任何業務含義。由此得知，將傳統設計中的Service繼續劃分，得到應用服務與領域服
務。領域層和應用層的服務是相互合作，由應用Service指揮領域對象來解決問題。
如此劃分，可以使各層的結構和職責更加清晰，技術與業務進一步分離。
以上是我個人的理解，有不對之處還請指正。
另仔細閱讀
實戰DDD(Domain-Driven Design領域驅動設計)，
在該文中說到：“在JiveJdon3中，com.jdon.jivejdon.service.ForumService和Forum實體模型及其值對
象ForumState共同完成領域模型，其中ForumService屬于應用服務層；而后兩者屬于領域層；其他服務
ForumMessageService、AccountService和UploadService等都是此類性質。”在JiveJdon3中并沒有對
領域與應用Service進行明確的劃分，而是由ForumService來完成。JJ3的代碼我沒有看過，只是從這段文字還這樣判斷的，有不對之處還請
包含。請問，JJ3中是否對Service進行了劃分？如果沒有那么您是怎樣考慮的呢？
bangq：
非常有道理，Evans DDD中的Service和我們傳統的Service確實不一樣，它主要劃分為應用層服務和領域層服務以及基礎結構層服務。
在我的JJ3案例中，我沒有進行這種嚴格的分層分類，是以Web服務中的Service和操作Operations概念來區分的：
需要對外開放的、供客戶端調用的我命名為服務，當然這個服務里也可能會區分為應用服務和領域服務；不對外開放，供業務層內部使用的普通operations就作為普通組件來看待。
個人目前感覺：應用服務和領域服務區分需要非常敏感，而且目前沒有看到大大的好處。
有時，快速性 方便性確實必須注意，當然這個尺度是根據當事人的水平而定的。
無論如何，我們更應該來關注領域對象：也就是實體和值對象，當然，領域對象并不是無行為的對象，可以封裝一些業務規則，不是簡單的setter或getter行為。
不知你是如何想？
版主：
應用服務與領域服務的區分確實非常敏感且難以撐控，在較為復雜的應用中，應用服務與領域服務并不一定能夠完全實現分離。這就需要不斷地重構來完善，但并不一定能夠完美(個人觀點)。
我認同領域對象不應只是簡單的setter或getter，可以封裝一些業務規則。但前題是這些規則一定是它本身的職責才是，否則模型就會遭到破壞(面向對象的精要處)。
版主：
引用兩段文字來說明問題：
“OO編程的技術是一門代理的藝術。職責劃分明確，把接口定義好，把實現交給另外的類來做。首先把變化的部分和不變的部分 劃分出來。不變的部分，就成了框架。變化的部分，就是程序員自己做。 ”
領
域對象是可以有行為能力的，在Rod Johnson的《without
EJB》第10章《持久化》中有一段文字：“領域對象包含的邏輯，這里稱之為“domain logic”，這些domain
logic應該最小化的依賴于DAO，而我們討論的那些需要持久化操作參與的事務性邏輯，這里稱之為“workflow
methods”，這些“workflow methods”應該放在“business facade”，而不應該放在domain
object里面。可重用度很高的操作可能是domain logic，應該放在domain
object里面；比較難重用的控制邏輯方法，特別是可跨越多個domain object的操作則放在business facade
object里面。”
雖然領域對象是可以有行為能力的，但除領域對象之外一定是要業務對象的。業務對象應該操控多個領域對象的協作。并不是將所有的邏輯都塞到領域對象中。
bangq：
>但前題是這些規則一定是它本身的職責才是，否則模型就會遭到破壞(面向對象的精要處)。
所以，例如各種條件的查詢，這些條件的篩選功能也應該屬于規則，過去我們將數據篩選留給數據庫SQL語句完成，現在DDD認為篩選應該在內存中完成，SQL文本也是一種規則。
>除領域對象之外一定是要業務對象的
引用Rod 的話容易引起誤解，前面我們討論過，我們的模型分領域對象和服務，領域對象又分實體和值對象。那么Rod這個業務對象又是什么呢？如果是服務，我們一般不會將服務稱為對象，服務是一種組件模型，要么是服務，要么是操作operations
>Service層和Function層的關系應該是胃和小腸的關系一樣
這是很形象比喻，現在確實沒有這方面框架，Service層和Function層分離，從現在來看，好像更多還是分析領域的事情，必須由建模人員來指定哪些服務是應用還是領域。