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

Question

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

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

Teacher
  IList<Class>

Class
  Teacher
  IList<Student>

Student
  Class

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

Где здесь сладкое место, или я совсем скучаю по лодке?

Спасибо!

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

Answer 1

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

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

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

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

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

Если вы хотите войти в ТАКОЕ мышление, вам нужно, я полагаю (мое мнение здесь), немного отказаться от идеи богатого домена.Я называю эту новую концепцию сервис-ориентированным доменом (SO-домен).

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

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

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

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

Остальное сводится к проектированию интерфейса службы, поэтому получить класс для учителяу вас могут быть такие вещи, как List RetrieveTeacherClasses (teacherIdentifier).Чтобы добавить студента AddStudentToClass (Student, classId).

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

Pratik упоминает производительность, истинное повышение производительности в масштабе всей системы достигается не путем смещения размера графов объектов, нокак способность каждого сервиса в решении независимо масштабироваться.

Вот несколько ссылок на дополнительные сведения об этих идеях

Создание SOA

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

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

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

SOA для вашего босса

Производительность службы WCF

Answer 2

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

Answer 3

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

Answer 4

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