Сервис-ориентация против объект-ориентации - могут ли они сосуществовать?

Question

В моей компании недавно проявился большой интерес к Сервис-ориентированной архитектуре (SOA). Всякий раз, когда я пытаюсь понять, как мы можем это использовать, я всегда сталкиваюсь с ментальным блоком. Грубо говоря:

• Объектная ориентация гласит: «объединяйте данные и методы, которые манипулируют данными (бизнес-процессами) вместе»;

• Сервис-ориентация гласит: «сохраняйте бизнес-процесс в сервисе и передавайте ему данные».

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

У меня такой вопрос: Какие шаблоны, архитектуры, стратегии и т. Д. Позволяют SOA и OO работать вместе?

---

Редактировать: Ответы "OO для внутренних объектов, SOA для системных границ" велики и полезны, но это не совсем то, к чему я стремился.

Допустим, у вас есть объект Account, в котором есть бизнес-операция с именем Merge, которая объединяет его с другой учетной записью. Типичный ОО подход будет выглядеть так:

Account mainAccount = database.loadAccount(mainId);
Account lesserAccount = database.loadAccount(lesserId);

mainAccount.mergeWith(lesserAccount);

mainAccount.save();
lesserAccount.delete();

В то время как эквивалент SOA, который я видел, выглядит следующим образом:

Account mainAccount = accountService.loadAccount(mainId);
Account lesserAccount = accountService.loadAccount(lesserId);

accountService.merge(mainAccount, lesserAccount);
// save and delete handled by the service

В случае OO бизнес-логика (и понимание сущности благодаря шаблону ActiveRecord) включаются в класс Account. В случае SOA объект Account на самом деле представляет собой просто структуру, поскольку все бизнес-правила скрыты в службе.

Могу ли я одновременно иметь богатые функциональные классы и повторно используемые услуги?

Answer 1

SOA - это хорошая архитектура для связи между системами или приложениями.

Каждое приложение определяет «сервисный» интерфейс, который состоит из запросов, которые он будет обрабатывать, и ожидаемых повторных запросов.

Ключевыми моментами здесь являются четко определенные сервисы с четко определенным интерфейсом. То, как на самом деле реализуются ваши сервисы, не имеет значения для SOA.

Таким образом, вы можете свободно внедрять свои услуги, используя все самые последние и самые лучшие методы ОО или любую другую методологию, которая работает для вас. (Я видел крайние случаи, когда «сервис» внедрялся фактическими людьми, вводящими данные на экран - и все же это все еще был учебник SOA!).

Answer 2

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

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

Answer 3

Я действительно считаю, что SOA полезен только для внешних интерфейсов (вообще говоря, для тех, кто находится за пределами вашей компании), и даже тогда, только в тех случаях, когда производительность не имеет большого значения, вам не требуется заказанная доставка сообщений.

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

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

Answer 4

Я слышал, как Джеймс Гослинг сказал, что можно внедрить SOA в COBOL.

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

Рассмотрим это описание:

Ваш X должен состоять из Ys. Каждый Y должен отвечать за единую концепцию и должен быть полностью описан в терминах его интерфейса. Один Y может попросить другой Y сделать что-то через обмен сообщениями (согласно их указанным интерфейсам).

В некоторых случаях X может быть реализован с помощью Z, которым он управляет в соответствии со своим интерфейсом. Никакой X не разрешен прямой доступ к другой X's Z.

Я думаю, что возможны следующие замены:

Term      Programing       Architecture
----    ---------------    ------------
  X         Program           System
  Y         Objects          Services
  Z      Data structure      Database
----    ---------------    ------------
result        OOP              SOA

Если вы думаете в первую очередь с точки зрения инкапсуляции, сокрытия информации, слабой связи и интерфейсов черного ящика, то здесь есть некоторое сходство. Если вы увязли в полиморфизме, наследовании и т. Д., Вы думаете о программировании / реализации вместо архитектуры, ИМХО.

Answer 5

Я думаю, что это неправильное понимание ориентации объекта. Даже в Java методы обычно не являются частью объектов , а их класса (и даже это «членство» не является необходимым для ориентации объекта, но это другой предмет) , Класс - это просто описание типа, так что это действительно часть программы, а не данные.

SOA и OO не противоречат друг другу. Служба может принимать данные, организовывать их внутри объектов, работать с ними и, наконец, возвращать их в любом формате.

Answer 6

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

Если им не разрешено сохранять состояние, то они, как вы сказали, - операторы данных.

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

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