Действительно ли DDD и SOA хорошо играют вместе?

Question

Пожалуйста, дайте мне знать, так мягко, если я полностью искажаю концепцию DDD, но вот моя дилемма.

Допустим, у меня есть следующий домен модель:

Teacher 
    IList<Class> 

Class 
    Teacher 
    IList<Student> 

Student 
    Class 

Теперь, с точки зрения DDD, похоже, Учитель мой корень, и действительно, в простом приложении, я мог бы нести вокруг моего Учителя с ее классами и учениками и действовать по мере необходимости. Но в ситуации SOA, допустим, я вытащил своего Учителя, ее классы и учеников для демонстрации (как dtos), и она хочет добавить ученика. Конечно, я не собираюсь отправлять весь объектный граф на сервер и извлекать объекты домена из базы данных, чтобы добавить нового ученика, не так ли?

Где находится сладкое пятно здесь, или я полностью не хватает лодки?

Спасибо!

Late Upate: Возможно, я отвечаю на свой вопрос, но я предполагаю, что один из моих подходов состоит в том, чтобы моя служба Teacher имела различные методы управления студентами (AddStudent, UpdateStudent), так что мой корень все еще управляет всем, а не одним сервисом на объект.

Answer 1

Вы думаете о производительности, но будете удивлены. В моих веб-сервисах SOA я использую такие полные графические объекты, и производительность в пределах допустимых пределов. Я бы предложил использовать бизнес-объекты и бизнес-методы в Интернете, например, SaveTeacher(Teacher t), если только не требуется использовать DTO для определения производительности и связанных с ними методов веб-поиска CRUD, например AddStudent(long teacherId, Student student)
Но даже если вы используете позднее, вы можете применить концепцию DDD, загрузив учителя из вашего персистентности хранить с учетом учителя, связать ученика и сохранить учителя обратно в хранилище персистентности.

Answer 2

Для SOA необходимо Услуги по применению. Взгляните на here, чтобы выяснить, где должна идти ваша функциональность.

Answer 3

Я бы сказал, что вы оба упускаете лодку и в то же время на правильном пути ... позвольте мне объяснить.

DDD - это лучший способ, который мы знаем как отрасль, чтобы кодировать реальность бизнес-задачи в область решений, которую мы можем сопоставить с компьютерной программой. DDD - это методология абстрагирования реального домена во что-то более управляемое и актуальное для нас, это хорошие вещи.

Проблема, с которой вы сталкиваетесь, заключается в реализации, преобладающим выбором реализации за последние 20-30 лет была объектная ориентация (OO), основным механизмом передачи объектов в OO является передача ссылок на объекты в такое же пространство памяти, как и вы. Таким образом, проблемы, с которыми вы сталкиваетесь в отношении крупных графиков объектов, где никогда не возникает реальной проблемы.

Ввести служебную ориентацию (SO), которая переворачивает вещи, вы больше не передаете ссылки на объекты, а обмениваете сообщения между службами. Теперь размер сообщения становится проблемой.

Если мы согласны с тем, что парадигма реализации изменилась, мы должны признать, что некоторые из наших лучших практик/шаблонов OO больше не применяются или нуждаются в пересмотре.

Если вы хотите проникнуть в SO-образ мыслей, вам нужно, я верю (мое мнение здесь), отвлечься от идеи богатого домена. Я назвал эту новую концепцию Service-Orientated-Domain (SO-Domain).

В SO-Domain состояние домена и поведение домена разделяются между передаваемыми вами сообщениями и услугами, которые вы используете.

Таким образом, состояние или атрибуты учителя являются частью TeacherDTO, но поведение является частью службы учителя.

В терминах OO это анемичный домен, но в смысле SO это не так уж плохо, так как это дает вам невероятную гибкость, поскольку у вас больше нет одной большой вещи, состояние может использоваться в нескольких контекстах ,

У вас все еще есть действующий домен, он просто разделен по-разному, сообщения хранятся в состоянии состояния и обслуживания.

Остальное относится к дизайну интерфейса службы, поэтому, чтобы получить класс для учителя, у вас могут быть такие вещи, как 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

Answer 4

Что Виджай говорит, чтобы добавить 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);