請讓我知道，永遠如此溫柔，如果我完全改變DDD的概念，但這是我的困境。DDD和SOA真的可以一起玩嗎？
比方說，我有以下的域模型：
Teacher
IList<Class>
Class
Teacher
IList<Student>
Student
Class
現在，從DDD的角度來看，這似乎是教師是我的根，而事實上，在一個簡單的應用程序，我會隨身攜帶我的老師與她的班級和學生一起根據需要採取行動。但是在SOA情況下，假設我已經拉下了我的老師，她的班級和學生用於顯示目的（如dtos），並且她想添加一個學生。當然，我不打算將整個對象圖發送到服務器，並從數據庫中檢索域對象，以便我可以添加新學生，對嗎？
這裏的甜蜜點在哪裏，還是我完全錯過了船？
謝謝！
延遲提交：也許我正在回答我自己的問題，但我想一種方法是讓我的教師服務有各種學生管理方法（AddStudent，UpdateStudent），以便我的根目錄仍在管理所有內容而不是一項服務每個對象。
您正在考慮性能，但您會感到驚訝。在我的SOA Web服務中，我使用這種完整的對象圖，性能完全在可接受的範圍內。我會建議使用業務對象和商業網絡方法，如SaveTeacher(Teacher t)，除非絕對需要使用DTO出於性能原因和相關的CRUD網絡方法，如AddStudent(long teacherId, Student student)
但即使使用更高版本，您也可以通過從持久性中加載教師來應用DDD概念給老師指定商店，附加學生並將老師保存回持久化商店。
對於SOA，您需要應用服務。看看here找出你的功能應該去哪裏。
我會說你們都錯過了船，並在同一時間在正確的軌道....讓我解釋一下。
DDD是我們作爲一個行業將商業問題的現實編碼到我們可以映射到計算機程序的解決方案領域的最佳方式。 DDD是一種將真實領域抽象爲對我們來說更易於管理和相關的方法，這些都是好事。
您所面臨的問題是在實現中，過去20 - 30年的主流實現選擇是面向對象（OO），在OO中傳遞對象的核心機制是將對象的引用傳遞給與您自己一樣的內存空間。所以你面臨的問題是大對象圖從來沒有真正的問題。
輸入服務方向（SO），可以翻轉事物，不再傳遞對象的引用，而是在服務之間交換消息。消息的大小現在成爲一個問題。
如果我們接受實施模式已經改變，我們需要接受我們的一些OO最佳實踐/模式不再適用或需要修訂。
如果你想進入SO的思維方式，你需要，我相信（我的意見），稍微放開一個豐富的域名的想法。我將這個新概念稱爲面向服務的域（SO-Domain）。
在SO域中，域的狀態和域的行爲在您傳遞的消息和您使用的服務之間被分開。
因此，教師的狀態或屬性是TeacherDTO的一部分，但行爲是教師服務的一部分。
從OO的角度來看，這是一個貧血的領域，但在SO的意義上，它並不是什麼壞事，因爲這給了你一些驚人的靈活性，因爲你不再有一件大事，這個狀態可以用在多種環境中。
您仍然有一個有效的域，它只是分區分區，消息保持狀態和服務保持行爲。
其餘的歸結爲服務界面設計，所以要爲班主任你可以有像List RetrieveTeacherClasses（teacherIdentifier）的東西。添加學生AddStudentToClass（Student，classId）。
有一百萬種不同的方式來做到這一點，你會發現一個適合你的方法，但作爲一般規則，你應該遵循一個狀態感知的範例，這意味着消息將發送任何狀態服務需要意識到這一點，這使服務成爲無狀態，而無狀態服務意味着可擴展性。 Pratik提到性能，系統範圍內真正的性能收益並不是通過對對象圖的大小進行大驚小怪，而是由於解決方案中的每個服務獨立擴展的能力。
這裏有一些鏈接到更多關於這些想法
嘿，這個答案真棒！我正在考慮用第二個帳戶註冊，以便我可以兩次註冊它。;-)真的，非常感謝這個解釋。 – Rafa 2012-02-22 14:04:48
什麼維傑要說的是增加一個TeacherService與傳遞addStudent方法
interface ITeacherService
{
Teacher GetTeacher (name teacher);
void AddStudent (Teacher teacher, Student student);
}
，那麼你最終會像下面這樣：
Student student = new Student ("Bobby Drop Tables;");
Teacher teacher = teacherService.GetTeacher ("Bob");
teacherService.AddStudent (teacher, student);
並沒有真正解決關於DDD和SOA是否相互正交的問題。 – 2010-12-16 01:07:57