Делить ли ваши сборки Service / API со своими клиентскими приложениями довольно субъективно. Если вы являетесь полным магазином Microsoft и используете .NET для всего своего стека приложений, то я бы сказал, что совместное использование API - отличный способ получить повторное использование кода (вы должны быть осторожны при разработке своего API, чтобы не истекать кровью вопросы, связанные с доменом, например, репозитории, в вашу презентацию.) Если у вас нет планов переноса клиентских приложений на другие платформы (т.е. вы планируете оставаться на .NET в обозримом будущем), то я думаю, что вполне приемлемо поделиться ваши сборки Service / API (и даже тогда, в многоплатформенной клиентской среде, совместное использование Service / API с клиентами .NET должно быть приемлемым). Всегда существует компромисс между «архитектурно идеальным» и «практичным и достижимым». в пределах бюджета'. Вы можете потратить ОЧЕНЬ много времени, денег и усилий, пытаясь достичь архитектурного идеала, когда разрыв между этим и практическим часто не так уж и велик. Выбор НЕ использовать API и по существу воссоздавать его для поддержания «правильной» SOA, потребляя только контракт, может фактически увеличить объем работы и создать трудности, связанные с обслуживанием, которые, вполне возможно, не стоят этого для вашего конкретного проекта в данное конкретное время. Учитывая, что вы, как правило, уже «ориентированы на обслуживание», если в будущем вам понадобится выгода, которую может предложить только контрактное потребление на клиенте, то вы уже готовы к этому. Но не торопитесь слишком рано.
Учитывая ваши потребности, насколько я могу судить по этим постам, я считаю, что вы на правильном пути и из ваших услуг. Репозиторий (а-ля Эванс, DDD) определенно является предметом беспокойства, и поэтому вам не нужно беспокоиться об этом с точки зрения уровня презентации. Ваши услуги являются воротами к вашему домену, который является домом вашей бизнес-логики. Репозитории - это всего лишь средство поддержки, которое помогает вам изолировать домен от хранилища данных (на самом деле они - прославленные коллекции, и, честно говоря ... они могут быть немного болезненными в динамической и сложной области. Простые средства отображения данных, (Фаулер, PofEAA) часто намного проще в обращении и менее сложен в долгосрочной перспективе, и позволяет более гибко настраивать поведение вашей логики поиска данных в ваших доменных службах.) Помимо интенсивного использования вызовов AJAX для служб REST , если вы предоставляете адекватные сервисы / API для своего домена, это единственное, о чем должны беспокоиться ваши клиенты. Оберните всю остальную часть вашей бизнес-логики целиком в рамки вашего домена и держите своих клиентов как можно более легкими и абстрагированными от таких понятий, как «Репозиторий» или «Data Mapper» и еще много чего.
По моему опыту, единственной концепцией, не относящейся к сервису или API, которая должна распространяться через границу между клиентом и доменом, является Контекст ... и, как известно, может быть трудно пересечь эту границу в сервис-ориентированном приложении.