DDD和SOA真的能很好地协同工作吗？

Question

如果我完全破坏了DDD概念,请让我知道,这是我的两难选择.

假设我有以下域模型:

Teacher
  IList<Class>

Class
  Teacher
  IList<Student>

Student
  Class

现在,从DDD的角度来看,教师似乎是我的根,事实上,在一个简单的应用程序中,我可以随身携带我的老师和她的班级和学生,并根据需要采取行动.但是在SOA情况下,假设我已经将我的老师,她的班级和学生拉下来用于显示目的(如dtos),并且她想要添加一名学生.当然,我不会将整个对象图发送到服务器并从数据库中检索域对象,以便我可以添加一个新学生,对吧？

这里的甜蜜点在哪里,还是我完全错过了船？

谢谢!

迟到:也许我正在回答我自己的问题,但我想一种方法是让我的教师服务有各种学生管理方法(AddStudent,UpdateStudent),这样我的root仍然可以管理所有内容,而不是每个对象有一个服务.

Answer 1

我会说你们都错过了这条船,同时也在正确的轨道上......让我解释一下.

DDD是我们作为一个行业将业务问题的现实编入我们可以映射到计算机程序的解决方案域的最佳方式.DDD是一种将真实域抽象为更易于管理且与我们相关的东西的方法,这些都是好东西.

您面临的问题是在实现中,过去20 - 30年的主流实现选择是面向对象(OO),在OO中传递对象的核心机制是将引用传递给同一内存空间中的对象.你自己.所以你面临的问题是大对象图从来都不是真正的问题.

输入服务方向(SO),它会翻转事物,您不再传递对象的引用,而是在服务之间交换消息.消息的大小现在成为一个问题.

如果我们接受实施范式已经改变,我们需要接受我们的一些OO最佳实践/模式不再适用或需要修改.

如果你想进入思维方式,我相信(我的观点在这里),稍微放开一个富域的想法.我将这个新概念称为面向服务的域(SO域).

在SO域中,域的状态和域的行为在您传递的消息和您使用的服务之间分配.

因此,教师的状态或属性是TeacherDTO的一部分,但行为是教师服务的一部分.

在OO术语中,这是一个贫血领域,但从某种意义上来说,这并不是一件坏事,因为这会给你一些惊人的灵活性,因为你不再拥有一件大事,状态可以用在多种情境中.

您仍然拥有一个有效的域,它只是差异化分区,消息保持状态和服务保持行为.

其余的归结为服务界面设计,所以为了获得教师的课程,你可以拥有像List RetrieveTeacherClasses(teacherIdentifier)这样的东西.添加学生AddStudentToClass(Student,classId).

有一百万种不同的方法可以找到适合您的方法,但作为一般规则,您应该遵循状态感知范例,这意味着消息将发送服务需要注意的任何状态,这使服务成为无状态,无状态服务意味着可扩展性.

Pratik提到性能,系统范围内的真正性能提升不是通过讨论对象图的大小,而是作为解决方案中每个服务独立扩展的能力.

以下是一些关于这些想法的更多链接

构建SOA

SOA设计模式

在SOA中实现完整性

为什么你的SOA应该像大众甲壳虫一样

SOA为您的老板解释

WCF服务性能

Answer 2

你正在考虑性能，但你会感到惊讶。在我的 SOA Web 服务中，我使用了如此完整的对象图，并且性能完全在可接受的范围内。我建议使用业务对象和业务 Web 方法，除非SaveTeacher(Teacher t)出于性能原因绝对需要使用 DTO 和相关的 CRUD Web 方法，例如AddStudent(long teacherId, Student student)
但即使使用后者，您也可以通过从持久性存储中加载教师来应用 DDD 概念（给定教师 ID） ，附加学生并将教师保存回持久存储。