Я не думаю, что ваш дизайн слишком далеко от того, где он должен быть.
Если у вас есть приложения, которые будут получать доступ к финансовым данным через службу WCF или службу транспорта, их имеет смысл создать. Их также имеет смысл создавать, потому что каждый из этих сервисов просто поддерживает то, что ему нужно знать (связано с принципом единой ответственности).
Там, где вам может показаться неправильным, ваше приложение UI должно знать об этом и вызвать 3 отдельные службы, чтобы выполнить свою работу. В подобных ситуациях мы часто строим сервис-оболочку, который вызывает соответствующий сервис. Это означает, что ваше приложение пользовательского интерфейса будет ссылаться на службу WCF, а затем эта служба будет вызывать службу финансов, службу транспорта или службу утверждений. Недостаток - каждый вызов приводит к нескольким вызовам ... да. Но он абстрагирует логику от вашего пользовательского интерфейса и дает вам преимущество, позволяя вам манипулировать или комбинировать данные из других сервисов или добавлять другую бизнес-логику, подходящую для приложения. Вы также по-прежнему получаете выгоду от службы «Финансы», которая по-прежнему поддерживает финансовые приложения, не мешая бизнес-потребностям вашего пользовательского интерфейса или мешая работе кода.
Я уверен, что для этого есть разные пути решения. Именно так мы и обработали несколько приложений.
РЕДАКТИРОВАТЬ (для ответа на дополнительный вопрос потребовалось слишком много места, чтобы оставить комментарий).
Если данных, которые вы можете получить из службы транспорта, достаточно для того, чтобы ответить на вопрос, заданный «getCustomerDelieveries», то нет, я бы не стал разбивать их на другую службу оболочки. Если вам нужно больше данных, то какие другие приложения также выиграют от этой услуги, предоставляющей больше информации о клиентах? Эти приложения полагаются только на транспортную службу? Это один из тех случаев, когда ответ должен «чувствовать» вас правильно, поскольку вы больше всего знаете о своих системах.
Возможно, вам нужно нарушить правило SRP, и ваша транспортная служба получит больше информации о клиенте из финансовой базы данных или службы. Или, если приложениям, которые полагаются на транспортную службу, обычно требуется больше данных о клиентах, можно подумать о расширении таблицы клиентов в базе данных транспорта.
Ни одно правило, принцип или философия не должны применяться так жестко, чтобы их нельзя было нарушить, если это имеет больше смысла для вашего приложения. Это будет баланс, и нет правильного или неправильного ответа, только то, что работает лучше для этой ситуации.
Вы начали этот пост с обсуждения нового приложения с пользовательским интерфейсом, которое будет поддерживать часть требований в вашем бизнесе, и для него нужны как финансовые, так и транспортные данные (а также собственные данные). Это идеальный кандидат для вызова службы оболочки. Требуются данные из 3 отдельных и отдельных источников данных. Ваша транспортная служба имеет ограниченную информацию о клиентах, которая хорошо работает для некоторых приложений, но, возможно, не так хорошо для других. Если вы напишите обертку, которая на 100% отражает вашу транспортную службу и дополнительно предоставляет немного больше данных о клиентах, что вы получили? Больше данных для приложений, которые их используют, но и больше обслуживания для вас, когда вы добавляете функциональность в транспортную службу. Какое еще значение может предоставить эта оболочка?
В этом случае, мне кажется, что транспортная служба получает больше данных о клиентах от финансовой службы "чувствует" лучше. В вашей базе данных транспорта есть некоторые данные, но их недостаточно. Это похоже на то, что транспортная служба должна восполнить этот недостаток, заполнив необходимые данные.