Сервис-ориентированная архитектура действительно связана с сопряжением и, как и любая другая архитектура, не слишком заинтересована в реализации.
В идеале необходимо разделить сервисы для предоставления автономной функциональности. Как этот сервис реализован, не имеет значения. Вы даже можете использовать функциональность устаревшего монолитного приложения.
Вместе с муфтой идет то, что я называю достижимость . Вам нужно выполнить некоторый код, и есть несколько способов сделать это:
- копирование и вставка
- вызов существующей функции
- справочная сборка
- вызов по проводам / вне процесса
Чтобы иметь автономных бизнес-компонентов , вам необходимо иметь некоторую стратегию развертывания. Вот где все становится более сложным, так как обновление устаревшей системы, предоставляющей сервисы, намного сложнее, чем, скажем, ограниченный контекст (на языке проектирования на основе домена) в виде микросервиса.
Клиент-серверные реализации могут очень сильно походить на SOA, если ваш сервер предоставляет сервисы довольно простым способом (например, REST API). Если вы смотрите на вещи с достаточно высокого уровня, они начинают выглядеть очень похожими. В этом отношении SOA на самом деле довольно старая шляпа, и хотя у нас есть «более новые» методы, они по-прежнему подпадают под баннер SOA.