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

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

Скажем, у меня есть следующая модель домена:

Teacher
  IList<Class>

Class
  Teacher
  IList<Student>

Student
  Class

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

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

Спасибо!

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

Ответ 1

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

Ответ 2

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

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

Вот несколько ссылок на эти идеи.

Создание SOA

Шаблон проектирования SOA

Достижение целостности в SOA

Почему ваша SOA должна быть как VW Beetle

SOA объяснил вашему боссу

Производительность сервиса WCF

Ответ 3

Что Vijay говорит, это добавить 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);

Ответ 4

Для SOA вам нужны Службы приложений. Посмотрите здесь, чтобы выяснить, где должна работать ваша функциональность.