如果我完全破坏了 DDD 概念，请让我知道，非常温和，但这是我的困境。
假设我有以下域模型:
Teacher
IList<Class>
Class
Teacher
IList<Student>
Student
Class
现在，从 DDD 的角度来看，老师似乎是我的根，实际上，在一个简单的应用程序中，我可以随身携带老师和她的类(class)和学生，并根据需要采取行动。但是在 SOA 情况下，假设我出于显示目的(作为 dtos)删除了我的老师、她的类(class)和学生，并且她想添加一个学生。当然，我不会将整个对象图发送到服务器并从数据库中检索域对象，这样我就可以添加一个新学生，对吧？
这里的最佳点在哪里，还是我完全错过了这条船？
谢谢!
Late Upate:也许我正在回答我自己的问题，但我想一种方法是让我的教师服务具有各种学生管理方法(AddStudent、UpdateStudent)，这样我的根仍然管理所有内容，而不是每个对象都有一个服务。
最佳答案
我会说你们都错过了这条船，同时在正确的轨道上……让我解释一下。
作为一个行业，DDD 是我们将业务问题的现实编码为我们可以映射到计算机程序的解决方案域的最佳方式。 DDD 是一种将真实领域抽象为对我们来说更易于管理和相关的方法，这些都是好东西。
您面临的问题是在实现中，过去 20-30 年流行的实现选择是面向对象 (OO)，在 OO 中传递对象的核心机制是通过传递对相同内存空间中的对象的引用你自己。因此，您面临的关于大型对象图的问题从来都不是真正的问题。
输入翻转事物的面向服务 (SO)，您不再传递对对象的引用，而是在服务之间交换消息。消息的大小现在成为一个问题。
如果我们接受实现范式已经改变，我们需要接受我们的一些 OO 最佳实践/模式不再适用或需要修改。
如果你想进入 SO 的思维方式，你需要，我相信(我的观点在这里)，稍微放弃富域的想法。我将这个新概念称为面向服务的域(SO-Domain)。
在 SO-Domain 中，域的状态和域的行为在您传递的消息和您使用的服务之间分开。
所以教师的状态或属性是 TeacherDTO 的一部分，但行为是教师服务的一部分。
在 OO 术语中，这是一个贫乏的领域，但从某种意义上说，这并不是一件坏事，因为这给了您一些惊人的灵 active ，因为您不再拥有一件大事，状态可以在多种情况下使用。
您仍然有一个有效的域，它只是进行了差异分区，消息保持状态，服务保持行为。
其余的归结为服务接口(interface)设计，因此要为教师获取类(class)，您可以使用 List RetrieveTeacherClasses(teacherIdentifier) 之类的东西。添加学生 AddStudentToClass(Student, classId)。
有一百万种不同的方法可以做到这一点，您会找到适合您的方法，但作为一般规则，您应该遵循状态感知范式，这意味着消息将发送服务需要了解的任何状态，这使服务无状态，无状态服务意味着可扩展性。
Pratik 提到了性能，系统范围内的真正性能提升不是通过关注对象图的大小来实现的，而是解决方案中每个服务独立扩展的能力。
以下是有关这些想法的更多链接
Building a SOA
SOA Design Pattern
Achieving integrity in a SOA
Why your SOA should be like a VW Beetle
SOA explained for your boss
WCF Service Performance
关于domain-driven-design - DDD 和 SOA 真的可以很好地协同工作吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4351170/