Шаблон Уровня служб - мы могли избежать уровня служб на конкретном случае?
мы пытаемся реализовать приложение с помощью причины Шаблона Уровня служб наши потребности приложения соединиться с другими несколькими приложениями также, и гугля в сети, мы нашли, что эта ссылка демонстративной диаграммы для "правильного" способа применяет шаблон:
martinfowler.com - Шаблон уровня служб
Но теперь у нас есть вопрос: что, если наша система должна реализовать некоторую бизнес-логику, только для нашего приложения (как некоторые данные обслуживания для самой системы), что мы не должны совместно использовать с другими системами. На основе этой диаграммы:
Как это кажется, будет ненужным реализовать уровень служб только для этого; это будет более практично, чтобы избежать уровня служб и просто пойти от Пользовательского интерфейса до Бизнес-Слоя (например). Каков должен быть правильный путь в этом случае для реализации Шаблона Уровня служб? Что Вы предлагаете нас для сценария как тот, который я сказал Вам?
Заранее спасибо.
2 ответа
«Уровень обслуживания» - это просто абстракция над логикой вашего домена. Абстракция может быть любой степени, в том числе прозрачной.
Термин «слой» вводит в заблуждение. Я думаю, что сам Мартин согласился бы, что это лучше называть границей контекста (от дизайна, управляемого предметной областью). Это означает, что у вас может быть много уровней обслуживания, которые в разной степени абстрагируют ваш домен. API «уровня» службы, который вы предоставляете своему пользовательскому интерфейсу, может делать гораздо больше в вашем домене, чем уровень службы, который вы предоставляете шлюзу интеграции.
Я бы порекомендовал разбить эти службы по функциональным контурам. (Например, набор служб, которые используются для массового импорта данных, и набор служб, с которыми обычно взаимодействуют пользователи, должны быть почти полностью разделены.) Таким образом, если вам нужно предоставить API другому приложению, которое, как вы ожидаете, будет взаимодействовать с вами. точно так же, как пользователь, вы можете заставить их использовать тот же API, что и пользовательский интерфейс.
Как упоминалось в опубликованной вами ссылке, уровень сервиса определяет «интерфейс» для клиентов, инкапсулируя (сложную) бизнес-логику и централизовав управление транзакцией с участием нескольких ресурсов. Уровень сервисов не только используется, когда вам нужно «поделиться» сервисами, он просто упрощает работу. Но даже при наличии одного потребителя централизация управления транзакциями имеет смысл.