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