На практике в хорошо спроектированных системах большинство сервисов, которые мне встречались, содержали только один или два контракта, при этом один контракт встречался чаще. Из сервисов с двумя и более контрактами дополнительные контракты почти всегда не были связаны с бизнесом; в них отражались такие аспекты, как безопасность, защита данных, хранение данных и т.д., и эти контракты повторно использовались в других сервисах.
Сервис не должен поддерживать более одного или двух контрактов. Поскольку контракты являются независимыми гранями сервисов, если сервис поддерживает три и более независимых бизнес-аспекта, это наводит на мысль о том, что сервис слишком велик.
Отказ от использования свойств также является хорошей практикой в любой распределенной системе. Всегда лучше хранить данные там, где они находятся, и только активизировать для них нужные операции.
Такие взаимодействия должны выражаться именами вида СделатьНечто()
В контексте контрактов сервисов следует избегать свойств и операций, имитирующих свойства. Свойства подразумевают наличие состояния и подробности реализации. Когда сервис предоставляет доступ к свойствам, клиент знает о таких подробностях, и при изменении сервиса клиент (или клиенты) должен измениться вместе с ним. Не стоит заставлять клиента пользоваться свойствами и даже знать о них. Хорошие контракты сервисов позволяют клиентам вызывать абстрактные операции, не беспокоясь об их фактической реализации. Клиент просто вызывает операцию, а дальше сервис должен беспокоиться о том, как поддерживать свое состояние.
Оптимальное количество операций на контракт сервиса лежит в диапазоне от 3 до 5. Если вы спроектировали контракт сервиса с большим количеством операций (например, от 6 до 9), это все еще относительно неплохо, но вы начали отклоняться от области минимальных затрат на рис. Б.4. Присмотритесь к операциям и определите, нельзя ли свернуть какие-либо из них в другие операции, чтобы избежать чрезмерной детализации. Если сервис содержит одну и более операций, то с очень большой вероятностью это является признаком плохой архитектуры.
Использует ли она слишком много параметров? Может, она недостаточно детализирована и одну операцию стоит разложить на несколько операций? Не стоит ли выделить эту операцию в существующий контракт сервиса? А может, ее лучше разместить в следующей подсистеме, которую вы собираетесь построить?
Контракты сервисов всего с одной операцией возможны, но их следует избегать. Контракт сервиса является гранью сущности, однако эта грань должна быть довольно примитивной, если ее можно выразить всего одной операцией.
Можно измерить, сколько раз каждый контракт повторно используется в системе и сколько раз контракт был изменен: очевидно, контракт, который повторно используется повсюду и не изменяется, может считаться хорошим.
можно измерить цикломатическую сложность кода.
