Исходя из вашего описания, я предполагаю, что каждая служба, которую вы создаете, сосредоточена вокруг определенной сущности, а когда ваша доменная модель требует разных сущностей, ей нужно использовать другую службу.
Если это так, я бы предположил, что сервис слишком мелкозернистый. Я бы предложил построить интерфейсы для ваших сервисов вокруг процессов, которые должны быть выполнены, с частью модели предметной области реализации этих сервисов. Насколько я понимаю, SOA рекомендует представлять систему как набор сервисов, однако внутреннее взаимодействие компонентов единой системы не должно быть сервисами.
Этот подход приводит к модели с расширенным доменом, использующей агрегированные корни в качестве средства связывания сущностей и основы для хранилищ, причем службы располагаются поверх этого, демонстрируя грубое поведение, а не базовое взаимодействие с какой-либо одной сущностью. Клиентские приложения, которые являются внутренними для вашей системы, могут обеспечить это (используя ту же модель домена).
Если сущности в вашей модели связаны, и эти взаимосвязи важны для поведения системы, тогда эти взаимосвязи следует применять (чтобы система отражала моделируемый домен), это будет трудно сделать, если каждая сущность независима особенно если это услуги.
В итоге вы получите систему, в которой все сервисы сущностей должны вызывать друг друга (создавая множество связей, увеличивая накладные расходы на управление изменениями и т. Д.), Или вы не сможете навязать взаимосвязи, что будет означать разбавление вашей модели. и может привести к непоследовательному поведению или отсутствию данных.
Это в основном сводится к базовым принципам High Cohesion и Low Coupling, которые являются противоборствующими силами, необходимо попытаться сбалансировать их в решении. Если у вас нет отношений (или неявных), то вы получаете низкую связь за счет сплоченности и, возможно, создаете проблемы обслуживания, если действительно существуют отношения, которые не представлены, или увеличиваете зависимости на более высоком уровне. Если вы навязываете слишком много отношений, вы в конечном итоге превратите свою модель предметной области в грязь и неуправляемость. Конкретный совет по этому вопросу является сложным, однако, как правило, я бы начал с построения модели с агрегатами, сосредоточив внимание на отношениях внутри агрегата и часто просматривая модель.
Специально для NHibernate я бы предложил продемонстрировать чистую абстракцию, которую он обеспечивает, сокращение необходимого кода, простую настройку без изменения кода и объем предоставляемых функций, например. идентификационные карты и единицы работы и т. д.