SOA - Насколько детализированы должны быть службы, чтобы поддерживать производительность?

Я беру на себя проект по замене древней устаревшей системы с нуля. До моего прихода компания наняла консультанта, который составил базовый набросок системы и активно продвигал SOA. В результате получился длинный список «сервисов сущностей» с намерением объединить их в более сложные комбинации сервисов. Например, пользователь, желающий получить информацию о комитете, попадет в службу "Комитет", которая затем вызовет службу "Человек", чтобы получить своих членов, и служба «Встречи», чтобы проводить встречи и т. д.

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

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

Итак, у меня вопрос - какой уровень детализации приемлем для стабильных сервисов без ущерба для производительности? Не слишком ли я скептически отношусь к снижению производительности, которое мы получим при реализации всех наших сущностей как сервисов? Если функциональность будет доступна в виде веб-сервисов только тогда, когда они необходимы, с «подготовкой» сосредоточиться вместо этого на разработке бизнес-уровня с учетом вероятности того, что сервисы позже будут удалены поверх него?