Do DDD and SOA really play well together?

Question

Please let me know, ever so gently, if I am totally mangling the DDD concept, but here is my dilemma.

Let\'s say I have the following domain model:

Teach         


        

Answer 1

I would say you are both missing the boat, and at the same time on the right track.... let me explain.

DDD is the best way we know as an industry to codify the reality of a business problem into a solution domain that we can map to a computer program. DDD is a methodology to abstract a real domain into something more manageable and relevant for us, these are good things.

The problem you are facing is in the implementation, the prevailing implementation choice for the last 20-30 years has been object orientation (OO), the core mechanism of passing objects around in OO is by passing references to objects in the same memory space as yourself. So the problems you are facing about large object graphs where never a real problem.

Enter Service orientation (SO) which flips things around, you are not longer passing references to objects, but exchanging messages between services. The size of the message now becomes a concern.

If we accept that the paradigm of implementation has changed, we need to accept that some of our OO best practices/patterns either no longer apply or need revision.

If you want to get into the SO way of thinking, you need to, I believe (my opinion here), let go of the idea of a rich domain slightly. I term this new concept a Service-Orientated-Domain (SO-Domain).

In a SO-Domain the state of the domain and the behavior of the domain is split between the messages you pass and the services you use.

So the state or the attributes of the teacher are part of the TeacherDTO, but the behavioral is part of the teacher service.

In OO terms this is an anemic domain, but in a SO sense it is not such a bad thing as this gives you some amazing flexibility, as you no longer have one big thing, the state can be used in multiple contexts.

You still have a valid domain, it is just partitioned differentially, messages hold state and services hold behavior.

The rest comes down to service interface design, so to get the class for a teacher you could have things like List RetrieveTeacherClasses(teacherIdentifier). To add a student AddStudentToClass(Student, classId).

There are a million different way to do this you will find the one that works for you, but as a general rule you should follow a state-aware paradigm, this means the message will send any state the service needs to be aware off, this enables the service to be stateless, and stateless service mean scalability.

Pratik mentions performance, true performance gains on a system wide scale are not made by fussing over the size of object graphs, but as the ability of every service in the solution to scale independently.

Here are some links to more on these ideas

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

Answer 2

You are thinking about performance, but you will be surprised. In my SOA web services I use such complete object graphs and performance is well within acceptable limits. I would suggest to use business objects and business web methods like SaveTeacher(Teacher t) unless absolutely required to use DTOs for performance reason and associated CRUD web methods like AddStudent(long teacherId, Student student)
But even if using the later you can apply the DDD concept by loading the teacher from your persistence store given the teacherId, attaching the student and saving the teacher back to persistence store.

Answer 3

What Vijay is saying is to add a TeacherService with an AddStudent method

interface ITeacherService
{
  Teacher GetTeacher (name teacher);
  void AddStudent (Teacher teacher, Student student);
}

So then you would end up with something like the following:

Student student = new Student ("Bobby Drop Tables;");
Teacher teacher = teacherService.GetTeacher ("Bob");
teacherService.AddStudent (teacher, student);

Answer 4

For SOA, you need Application Services. Take a look here to figure out where your functionality should go.