Насколько важно сделать уровень обслуживания?

Я начал создавать приложение в 3 слоя (DAL, BL, UI) [оно в основном обрабатывает CRM, некоторые отчеты о продажах и инвентарь].

Коллега сказал мне, что я должен перейти к шаблону сервисного уровня, что разработчики пришли к сервисному шаблону из своего опыта, и это лучший подход для разработки большинства приложений. Он сказал, что таким образом будет легче поддерживать приложение в будущем.

Лично у меня такое ощущение, что это просто усложняет ситуацию, и я не вижу в этом особой пользы, которая бы это оправдывала.

Это приложение имеет дополнительный небольшой частичный пользовательский интерфейс, который использует некоторые (но только несколько) функций настольного приложения, поэтому я обнаружил, что дублирую некоторый код (но не очень). Просто из-за некоторого дублирования кода я не стал бы конвертировать его в сервис-ориентированный, но он сказал, что я все равно должен его использовать, потому что в целом это очень хорошая архитектура, почему программисты так увлечены услугами?

Я пытался гуглить на нем, но я все еще в замешательстве и не могу решить, что делать.

Книга Мартина Фаулера «Образцы архитектуры предприятия» гласит:

Легче всего ответить на вопрос, вероятно, когда им не пользоваться. Скорее всего, вам не нужен сервисный уровень, если бизнес-логика вашего приложения будет иметь только один тип клиента - скажем, пользовательский интерфейс - и его ответы в сценариях использования не включают несколько транзакционных ресурсов. [...]

Но как только вы представляете второй тип клиента или второй транзакционный ресурс в ответах на варианты использования, он платит за разработку на уровне обслуживания с самого начала.

Преимущества, предоставляемые сервисным уровнем, заключаются в том, что он определяет общий набор операций приложения, доступных для разных клиентов, и координирует ответ в каждой операции. Если у вас есть приложение, которое имеет более одного вида клиентов, которые используют свою бизнес-логику и имеют сложные варианты использования, включающие несколько транзакционных ресурсов, имеет смысл включить уровень обслуживания с управляемыми транзакциями.

С CRM, Sales and Inventory будет много вариантов использования CRUD-типа, почти всегда однозначно соответствующих операциям уровня сервиса. Ответы на создание, обновление или удаление объекта домена должны координироваться и передаваться атомарно с помощью операций сервисного уровня.

Еще одним преимуществом наличия сервисного уровня является то, что он может быть разработан для локального или удаленного вызова, или для того и другого, и дает вам гибкость для этого. Шаблон закладывает основу для инкапсулированной реализации бизнес-логики приложения и последовательного вызова этой логики различными клиентами. Это означает, что вы также уменьшаете / удаляете дублирование кода, поскольку ваши клиенты используют одни и те же общие службы. Вы также можете потенциально снизить затраты на обслуживание - поскольку при изменении вашей бизнес-логики вам (как правило) нужно менять только услугу, а не каждого из клиентов.

Таким образом, полезно использовать уровень обслуживания - более того, поэтому я думаю, что в вашем примере вы предоставили, как будто у вас есть несколько клиентов бизнес-логики.

Добавление сервисного уровня, потому что вы оценили идею и пришли к выводу, что лучший подход: хорошо

Добавление сервисного слоя, потому что это то, что делают все классные дети: плохо

Если твоя интуиция говорит, что она тебе не нужна, не делай этого.

Одно из самых разочаровывающих событий в мире программирования за последние 10 лет - это то, что он стал раздражающе ориентированным на моду, когда люди следят за трендами и моделями, как будто они были в этом сезоне. Не попадитесь в эту ловушку. Потому что в следующем сезоне «все» скажут вам, что вы должны были спроектировать это по-другому.

В уровне обслуживания нет ничего плохого или неправильного - это особый подход, пригодность которого следует оценивать с точки зрения его технических преимуществ для данного проекта. Не чувствуйте себя обязанным заменять мнение других людей своим собственным мнением.

Есть много факторов, которые влияют на решение о создании сервисного уровня. Я создал сервисные слои в прошлом по следующим причинам.

1. Код, который должен быть повторно использован несколькими клиентами.
2. Сторонние библиотеки, на которые у нас ограниченные лицензии.
3. Третьи стороны, которым нужна точка интеграции в нашу систему.
4. Централизация дублированной бизнес-логики.

Случай 1: вы создаете базовую функциональность, которая должна использоваться множеством разных клиентов. Сервисный уровень обеспечивает функциональность для разных клиентов, чтобы использовать предоставленные вами функции прямо из коробки.

Случай 2. Обычно вы размещаете код в пространстве приложения, но используете стороннюю библиотеку, для которой у вас ограниченные лицензии. В этом случае у вас есть ресурс, который вы хотели бы использовать везде, но только ограниченное их количество. Если вы размещаете его за службой, тогда вся ваша организация может использовать его в своих приложениях, не покупая лицензию для каждого отдельного хостинга.

Случай 3: вы создаете функциональность для третьих сторон, чтобы общаться с вами. В вашем примере вы можете настроить конечную точку инвентаризации, чтобы поставщики могли передавать вам сообщения о входящих поставках продукта.

Случай 4: Вы проанализировали свой код в масштабах предприятия и обнаружили, что отдельные команды создали одно и то же (просто реализовали его немного по-разному). С сервисным уровнем вы можете выбрать лучший подход (ы), и теперь вы можете реализовать процесс одинаково для всех команд, заставив их обратиться в сервис. Еще одним преимуществом централизации логики является обнаружение ошибок. Теперь вы можете развернуть исправление один раз, и все клиенты одновременно получат выгоду.

Все это при том, что есть потенциальные негативы для уровня обслуживания.

1. Добавляет сложность системы. Если раньше у вас было только одно приложение для отладки, теперь у вас есть два. Производственные проблемы требуют проверки настроек клиентских приложений, настроек сервисных приложений или проблем связи между правильной настройкой клиентских и серверных приложений. Это может быть сложно, если вы никогда не делали этого раньше.
2. Одна точка отказа. Если у вас есть перерыв в обслуживании, все клиенты будут затронуты. Когда код не развернут таким образом, риск может быть меньше (хотя есть способы смягчить это).
3. Управление версиями может быть сложнее. Когда у вас есть одно приложение, использующее службу, развертывание интерфейса может быть изменено одновременно между ними. Когда у вас есть несколько клиентов, вы должны управлять тем, кто на V1, кто на V2, и координировать удаление V1 (как только вы узнаете, что все обновились до V2).

Суть в том, что ориентировать системный сервис не всегда сложно. По моему опыту это обычно хорошая идея (я склонен структурировать приложения таким образом), но это не автоматическое решение. В конце дня вам нужно взвесить все за и против и принять решение, которое подходит для вашей ситуации.

Большинство сервисных уровней, которые я видел, - полный беспорядок. Услуги, как правило, имеют много разных методов, 1500 LOC не редкость. Различные методы не имеют ничего общего, но делятся кодом. Это приводит к высокой сцепленности , низкой когезии . Это также нарушает OCP , потому что каждый раз, когда требуется новая операция, вы должны модифицировать код, а не расширять базу кода. Хорошо сконструированный сервисный уровень теоретически возможен, но я никогда не видел его на практике.

CQRS решает эти проблемы и не позволяет создавать один из этих процедурных уровней обслуживания.

Добавление интерфейса (сервисный уровень является типом интерфейса) требует времени. Хороший занимает много времени для разработки и тестирования. Очень важно сделать это правильно с первой попытки, потому что изменение этого позже ломает всех клиентов. Кроме того, учтите, что вы, вероятно, не будете знать, что должно быть в этом интерфейсе, пока у вас не появится второй клиент с немного другими потребностями. Поддержание сервиса - это бесконечный проект сам по себе.

В большинстве организаций, если вы обращаетесь к своему бизнес-спонсору и спрашиваете его: «Хотите ли вы, чтобы другие отделы пользовались (повторно использовали) этой системой, которую мы разрабатываем, с вашим бюджетом?» они будут смеяться над тобой. Сначала заставьте его работать для вашего бизнес-спонсора, а затем начните с повторного использования этого кода (в свободное время вашего отдела).

Если вы точно знаете, что функциональные возможности, которые вы пишете сегодня, будут повторно использоваться несколькими различными клиентами, то подумайте о разработке уровня обслуживания с первого дня. Если вы не уверены, или в проекте уже много неизвестных, сначала найдите что-то простое, а затем разделите его на службу и клиент, если у вас есть время и бюджет. Намного проще получить интерфейс сервиса прямо с первой попытки, когда вы начинаете работать с работающей системой.

PS Если вы работаете на Java, у Джошуа Блоха есть много фантастических советов по интерфейсу в его книге «Эффективная Java».

Я согласен. Нет необходимости включать еще один слой, если вы используете один пользовательский интерфейс.

DAL, BL и UI / Controller - хорошая комбинация для разработки приложения. Если вы планируете использовать один пользовательский интерфейс, нет необходимости готовить дополнительный слой. Включение еще одного слоя в приложение только увеличивает время разработки.

Другим преимуществом является использование нескольких пользовательских интерфейсов в вашем приложении, в этом случае полезно иметь сервисный уровень для обработки пользовательских интерфейсов.

Переполнение стека: обсуждение шаблона уровня обслуживания

Я бы поспорил, что ваш BL - это ваш уровень обслуживания Центральное место, где сидит ваша бизнес-логика. Это должна быть библиотека DLL, которая может использоваться всем, кому нужна эта логика. Затем вы можете поместить слой веб-API поверх этого, если ваше приложение будет иметь другой пользовательский интерфейс.